Skip to content

Customer POs — Workflow

Overview

A Customer PO (CPO) represents the customer's authorization to bill for project work. CPOs go through two distinct sub-workflows: an initial creation that goes directly to active, and a version creation that requires direction approval. Once active, the CPO tracks invoicing and payment progress until it is finalized.

Note

This feature follows SARA's standard record lifecycle model. See: Workflows & Pipelines

Roles involved

  • Project manager / Sales — Creates the first CPO on a project (from the Projects module) or requests a new CPO version when the customer issues an updated document.
  • Direction — Approves or rejects new CPO versions before they become active.
  • Finance — Registers invoices and payments; finalizes CPOs; handles mismatch reviews.

Status lifecycle

  • ACTV — Active. The CPO is the current valid version for the project; invoicing and payments can be registered.
  • INPG — In Progress. A new version was rejected by direction and returned for correction. The version can be edited and resubmitted, or cancelled.
  • APDR — Pending direction approval. A new version is waiting for direction to approve or reject it.
  • MISM — Mismatch. A finalization attempt found that invoiced or paid totals do not match the CPO amount. Requires review before a final decision.
  • FINA — Finalized. The CPO is closed. Can be reactivated if needed.
  • CANC — Cancelled. A version that was superseded by a newer version, or explicitly cancelled by the requester.

Info

For system-wide status guidance, see: Status

Status diagram

stateDiagram-v2
    [*] --> ACTV : First CPO created (no approval)

    ACTV --> APDR : New version requested
    CANC --> APDR : Previous versions cancelled on new version
    APDR --> ACTV : Approved by direction
    APDR --> INPG : Rejected by direction

    INPG --> APDR : Resubmitted for approval
    INPG --> CANC : Cancelled by requester

    ACTV --> MISM : Finalize — amounts mismatch
    MISM --> FINA : Mismatch approved
    MISM --> ACTV : Mismatch rejected (returns to active)

    ACTV --> FINA : Finalize — amounts match
    FINA --> ACTV : Reactivated

Workflow

Workflow steps

  1. First CPO is created in Projects → goes directly to ACTV
  2. Customer sends a revised document → new version created → APDR for direction review
  3. Direction approves → ACTV; or rejects → INPG → requester corrects and resubmits
  4. Finance registers invoices and payments as work is billed and collected
  5. Finance finalizes the CPO → FINA (or MISM if amounts differ)

First CPO creation

The first CPO for a project is created in the Projects module, from the CPO tab on a project detail. It goes directly to ACTV — no direction approval is needed for an initial CPO registration.

  • SARA assigns an internal folio (original_po) that becomes the stable identifier for this CPO family.
  • internal_version is set to 1.
  • Display code: CPO.{folio}.1.

New version

When the customer issues a revised CPO document, a new version is requested from the Projects module. The existing ACTV version is set to CANC and the new version enters APDR:

  • internal_version is incremented automatically by SARA (e.g., version 2, 3…). The user cannot set or modify this.
  • All active invoices, payments, and notes from the previous version are copied to the new one. The new version's po_usage and po_usage_payment are initialized from the copied totals.
  • Direction is notified to review the new version.

Direction approval

Direction reviews the new version from the Projects module (CPO tab) or from the Review modal in the Customer POs screen:

  • Approve → CPO moves to ACTV. Notification sent to users with pos new version permission.
  • Reject → CPO moves to INPG. Notification sent. The requester can then edit and resubmit, or cancel.

Note

When a version is rejected, a note is shown in the Review modal: "If rejected, the CPO will be returned to In Progress status for correction."

INPG correction flow

After rejection, users with pos new version can take one of three actions from the Customer POs list:

  • Edit — updates the CPO data in place (no new version row is created).
  • Submit for approval — moves CPO from INPG → APDR, restarting the direction review.
  • Cancel version — moves CPO from INPG → CANC. The project will have no active CPO until a new one is created.

Invoice and payment registration

Once a CPO is ACTV, finance registers invoices and payments from the Review modal:

  • Each invoice requires an amount and file upload. The invoice amount is added to po_usage.
  • Each payment requires an amount, date, account, and file upload. The payment amount is added to po_usage_payment.
  • Both invoice and payment records are copied forward when a new CPO version is created.
  • Auto-finalization: when po_usage equals the CPO total AND po_usage_payment equals the CPO total, SARA automatically sets the CPO to FINA.

Finalization

Finance triggers Finalize explicitly when work is complete. SARA compares the invoiced and paid totals against the CPO amount:

  • Match → CPO moves to FINA directly.
  • Mismatch → CPO moves to MISM. A user with mismatch cpos reviews the discrepancy from the Review modal and either approves finalization → FINA, or rejects → CPO returns to ACTV.

A finalized CPO (FINA) can be reactivated with the Activate row action (requires edit).

Notifications

  • Direction approval — email sent to direction when a new version enters APDR.
  • Version decision — email sent to users with pos new version permission when direction approves or rejects a version.
  • Mismatch review — email sent to finance team members with the relevant permission when a mismatch finalization decision is made.

Note

For global notification behavior, see: Notifications & Alerts

Setup & dependencies

  • CPOs are linked to projects. A project must exist before a CPO can be created.
  • The first CPO for a project is typically created automatically when a quote is approved (see Quotes).
  • Bank accounts must be configured in Bank Accounts to be selectable when registering payments.

Exceptions & operational notes

  • Dynamic budget projects: invoiced and paid percentages are not shown; the "Finalize" action still works but no amount comparison is made since there is no fixed total.
  • INPG after cancel: cancelling an INPG version leaves previous versions in CANC. The project will have no active CPO — a new CPO must be created from the Projects module.
  • Invoice/payment deletion: available from the Review modal while the CPO is not in APDR status. Deleting reduces po_usage or po_usage_payment accordingly.

Permissions

Permissions

Access and actions are permission-driven. See: Permissions