Vendor payments that reconcile themselves

The commit-then-pay sequence

Vendor spending goes wrong when the two events happen in the wrong order or get collapsed into one. The commitment — a purchase order issued against a budget line — is the moment the cost becomes real, because the money is encumbered against a category whether or not an invoice ever arrives. The payment — the invoice, approved and paid — is the second event, and it should confirm the commitment, not replace it.

Pay an invoice that no PO backs and the money leaves without a budget line knowing; issue a PO nobody reconciles against and the commitment grows past the category without anyone noticing. The discipline is trivial to state and hard to keep: commit first, code at the moment of commitment, and reconcile the invoice to the commitment before payment.

Start paperwork before the first dollar

Accounts payable isn't just money out — it's tax and liability exposure. A new crew member or vendor needs their start paperwork on file before the first payment: a W-9 or the local equivalent for the tax record, a certificate of insurance when the vendor operates equipment or works on set, and the contact and banking details the payment will be issued against. Chasing a W-9 after the check is cut means the year-end 1099s are wrong before they're printed.

The same logic applies to retention when the contract calls for it: holdbacks computed and tracked per vendor, released when the conditions are met. Retention computed informally is a dispute waiting for wrap.

Code at entry, approve in a chain, pay in a run

Every invoice enters with three facts attached: which budget line it pays against, which GL account it posts to, and which project it belongs to. An invoice coded at entry flows to the cost report and the ledger on its own; an invoice coded at wrap requires a human to remember, months later, which category the rental was for.

Approval should be a chain, not a single signature — draft, submitted, approved, paid — with the approver's name and date on each transition. The chain is what an auditor walks, and it's also what catches the two classic AP failures: the duplicate invoice and the invoice that doesn't match the PO's quantity or rate. Pay in scheduled runs rather than ad hoc, and the cash picture and the cost report agree on timing.

• •Code the invoice when it arrives: budget line, GL account, project.
• •Approve as a chain with names and dates at each transition.
• •Match the invoice to the PO — quantity, rate, total — before payment.
• •Pay in scheduled runs so the cost report and cash agree on timing.

How Clarice handles this

Clarice runs vendor payments as connected objects. Purchase orders issue against budget lines; vendor invoices link to the budget lines and POs they pay, carry their own approval chain with a full history, and post to a chart of accounts mapped from the budget's own categories — with journal entries created automatically as invoices are approved and paid.

The reconciliation view shows each budget line's estimated and committed and actual cost together, so a PO that outran its line is visible the week it happened. Remittances for crew draw on the same timecards the budget projected from, and the audit export packages the POs, invoices, approvals and ledger entries as one tied-out set.