Finance Index
Should invoice approval and payment approval be separate steps?
Reference guide to invoice vs payment approval separation, including control design, audit evidence, risk points, finance procedures, and compliance review.
Yes. Invoice approval confirms the liability is valid - the goods arrived, the price is right, the coding is correct. Payment approval authorizes cash movement - this amount, from this account, by this method, now. They answer different questions, carry different risks, and separating them puts a second independent gate between an error (or a fraud) and your bank account.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Invoice approval | Yes. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Approval path | Make approval status a hard precondition: only fully approved invoices are eligible for a payment run, enforced by the system rather than by the person building the batch. | Keeps evidence clear and reduces control risk. |
| Dual control on payment | Dual control means two people must act before funds move - one initiates or builds the payment, another independently approves release. | Keeps evidence clear and reduces control risk. |
| Payment impact | Someone with cash authority rather than spend authority - typically a controller, treasurer, or CFO depending on amount. | Keeps evidence clear and reduces control risk. |
| Related terms | Approving for payment marks the invoice as eligible; release is the act that actually moves funds - final authorization of a specific payment from a specific account on a specific date. | Reduces payment errors, timing issues, and reconciliation cleanup. |
How do I design the control handoff between invoice approval and payment release?
Make approval status a hard precondition: only fully approved invoices are eligible for a payment run, enforced by the system rather than by the person building the batch. Then separate the payment-side duties - the person who builds the run shouldn't be the one who approves its release, and release authority should follow amount thresholds the same way invoice approval follows a DOA. The handoff evidence matters too: the payment record should link back to the approved invoices it covers, so anyone can trace funds released -> payment approved -> invoices approved -> invoices validated, without leaving the system.
What is dual control on payment release, and how does it relate to upstream invoice approval?
Dual control means two people must act before funds move - one initiates or builds the payment, another independently approves release. It's the payment-side mirror of invoice approval separation, and the two layers are complementary, not redundant: invoice approval can't catch a fraudulent batch built from legitimate invoices, and payment approval can't validate whether goods were ever received. A payment run including invoices that were never formally approved is the precise failure this two-gate design prevents.
Who should approve payments if a different person already approved the invoice?
Someone with cash authority rather than spend authority - typically a controller, treasurer, or CFO depending on amount. The invoice approver validated the business reality; the payment approver validates the cash decision: timing, account, method, and that the run contains only what it should.
What is the difference between approving an invoice for payment and releasing/executing the payment?
Approving for payment marks the invoice as eligible; release is the act that actually moves funds - final authorization of a specific payment from a specific account on a specific date. Keeping them distinct means a payment can be staged, reviewed, and stopped before it becomes irreversible.
Our payment run includes invoices that were never formally approved - how do we put a hard gate between approval and payment?
Enforce it in-system: payment run eligibility filters on approval status, with no manual add of unapproved invoices. If your tooling can't enforce that, the compensating control is a pre-release reconciliation of the run against approval records - but treat that as a stopgap; this is a gate software should hold.
Should the person who builds the payment batch be allowed to approve it?
No - batch creation and batch approval are the core payment-side SoD pair. The builder selects what gets paid; the approver independently confirms it. Collapse them and one person controls cash movement end to end.
An approved invoice was modified after approval and before payment - what control prevents post-approval changes?
Two controls together: system behavior that treats material edits (amount, vendor, banking details) after approval as requiring re-approval - the prior approval applied to a different invoice - and an audit trail with before/after values so any post-approval change is visible. Payment-stage validation should re-check the invoice state, not trust a stale status.
Stampli perspective
Stampli treats payment approval as its own control layer, distinct from invoice approval by design. Payment approval workflows support one-, two-, and three-level configurations with amount-based thresholds, rules tied to the specific funding bank account, separate FX approval for foreign-currency payments, and delegation for coverage - so separation of duties between payment creation and payment release is enforced in the system. Pre-payment validation checks ERP status before funds move, and the approval history travels with the payment record.