The approval chain: why money waits for signatures

What an approval chain is for

An approval chain is the production's answer to a basic risk: the people who incur costs are not always the people accountable for them. The chain inserts the accountable party — the line producer, the production manager, the client — between the cost and the money, with each approval both a decision and a record of who made it.

The design is older than software: purchase requests signed by a department head, countersigned by the accountant, paid only on release. What changes with scale is that the chain's value shifts from the decision itself to the trail — on a production with hundreds of invoices a week, the question 'who approved this and when' is asked constantly, and only a recorded chain answers it.

The stages, and what each one protects

A workable chain has stages with distinct meanings. Submission declares the cost and asks for it to be paid. Review checks the math, the terms and the documentation — the invoice against the PO, the timecard against the deal memo. Approval commits the production's money. Payment releases it, and is recorded as its own event because approved-but-unpaid is a real state with real consequences for vendor relationships.

Rejection and return are stages too, and they're where weak chains leak: a returned invoice with no reason recorded comes back unchanged; a rejection without a note becomes a dispute. The stages protect different things — review protects the numbers, approval protects the budget, payment protects the relationships — and collapsing them into one 'paid it' event protects nothing.

• •Submission asks; review verifies; approval commits; payment releases.
• •Rejection and return are stages with reasons — undocumented ones repeat.
• •The history of the chain is the audit trail; the audit trail is the defense.

Holdbacks and the paid-until-the-end problem

Productions routinely hold back a percentage of vendor payments — retainage — against satisfactory completion, releasing it at wrap once punch-list items and disputes are settled. It's a legitimate protection that becomes a bookkeeping burden: the held amount is a liability tracked per vendor per invoice, sometimes for months, and a production that loses track of its own holdbacks either overpays or ends up in disputes with vendors who remember exactly what's owed.

The same mechanics apply in reverse with deposits and prepayments — money that has moved before the work is done, tracked as a credit against the eventual invoice. Both are just balances that must live somewhere structured, because 'we'll sort it out at wrap' is how the wrap gets complicated.

What an unapproved invoice actually is

An invoice that arrives without a chain behind it is a claim, not a cost. Treating claims as costs is how a production's numbers go quietly fictional: the cost report shows spend that hasn't been verified, the budget is silently consumed by invoices nobody checked, and the first honest reconciliation happens at wrap, which is far too late to dispute anything.

The chain's real function is to keep the record honest as it happens — each approval confirming that this cost is real, matched and in-budget, so the cost report, the GL and the audit export are all built from the same verified events rather than reconstructed afterward.

How Clarice handles this

Clarice runs approvals as a recorded chain: invoices, purchase orders and timecards each carry a stage — draft, pending, approved, rejected, paid — with every action logged as who, what and when, and rejection reasons captured so returned items come back fixed.

Vendor remittances track their holdback percentages and thresholds natively, paid invoices post to the GL on approval, and the approval surfaces across the app show what's waiting on whom — so 'who approved this' is one click, and the audit export ships with the chain attached.