In an illustrative scenario, when a department head signs a supplier invoice for 1,000 USB drives, company policy may dictate they merely confirm the goods arrived. Once the document reaches finance, this commercial approval does not automatically make the invoice ready for payment. Finance teams must still verify matching tolerances, check for duplicates, and prepare the register for bank authorization.
Separating commercial approval from financial control
In daily operations, distinguishing between acknowledging a business expense and authorizing a cash outflow is a critical internal control. Depending on company policy, a department head may evaluate an invoice solely based on operational reality, confirming equipment delivery. However, this operational sign-off is only the first step. The finance operations manager must protect the balance sheet and prevent erroneous disbursements. An approved invoice means the business accepts the liability, not that the document is mathematically correct or ready for bank execution.
Consider an explicitly illustrative scenario. A company issues a purchase order for 1,000 USB drives at $10.00 each. The vendor ships the items, and the warehouse registers the receipt. Later, an invoice arrives for $10,800. The department head approves it, confirming the delivery. If the system automatically executed this payment based solely on this commercial approval, the company would overpay by $800.
To prevent such leaks, the accounts payable process must intercept the document and subject it to financial validation. The finance team enforces the boundary between operational acceptance and the decision to release funds. This requires a structured workflow where receipt, invoice validation, payment-register preparation, authorization, and bank execution are distinct stages.
Sources: [1]
Three-way matching and variance tolerances
The primary mechanism for validating an invoice before payment preparation is three-way matching. This process compares the vendor invoice against the original purchase order and the registered product receipt. It ensures the company pays for the exact quantities received at the agreed prices. When the system detects differences, it generates matching discrepancies for formal resolution.
In our illustrative scenario, the quantity matches: 1,000 units ordered, received, and invoiced. However, the system identifies a price discrepancy. The net unit price on the invoice is $10.80, while the purchase order specifies $10.00. The software calculates the net unit price by dividing the line's net amount by its quantity, then compares it against the expected price.
Finance operations managers configure organization-approved variance tolerances and acceptance tests rather than relying on universal rules. For example, a company policy might allow a specific net unit price variance percentage for IT hardware. If the $10.80 price exceeds the company's defined threshold, the system flags the line with a match variance icon and halts the workflow. The invoice cannot proceed until an authorized financial controller investigates and explicitly overrides the policy.
Sources: [1]
Blocking duplicates and unallocated charges
The accounts payable workflow must defend against duplicate billing. Because an invoice number alone is not globally unique, financial software must check the combination of the invoice number, vendor identity, and other relevant attributes against previously posted documents. When a potential duplicate is detected, the system prohibits submission to the approval workflow. The operator verifies whether the vendor issued a corrected invoice, a credit note, or a genuine duplicate.
Another barrier to payment readiness is unallocated charges. Vendors frequently add supplementary costs like freight or expedite fees not included in the original purchase order. If an invoice arrives with a $50 expedite charge, the total will not equal the registered expected amount. The system flags these unallocated charges and blocks the document from the posting stage.
The accounts payable controller must review these supplementary costs and determine their accounting treatment. They allocate the charges to the appropriate expense lines or inventory costs. Only after resolving all variances and allocating every charge can the invoice be officially posted to the vendor balance.
Sources: [2]
Contract management as the baseline for verification
When a financial controller encounters a price discrepancy or an unexpected expedite fee, they must consult the original vendor agreement to determine if the extra charges are justified. If contracts are scattered across local drives, this verification grinds to a halt. Contract approval drags on, and appendices containing pricing tiers can be lost.
Finance teams require an electronic database for contract management. Products like the InBase Scriptum system serve as an implementation option to structure this data. Centralizing contracts ensures controllers have visibility into agreed terms. When investigating the $10.80 USB drive price, the controller searches the repository to check if the vendor is entitled to a price escalation due to expedited delivery.
Without access to the contract, the finance team relies on informal confirmations, complicating the audit trail. A structured contract management process ensures financial decisions are backed by documented evidence. The table below outlines the specific criteria an invoice must meet before payment preparation.
| Control stage | Acceptance criteria | Responsible role |
|---|---|---|
| Price variance | Within organization-approved tolerances | System or finance controller |
| Item quantity | Matches product receipt | Warehouse worker |
| Document uniqueness | Verified by number and vendor identity | System and operator |
| Contract terms | Match contract database | Process owner |
Sources: [3]
Payment batch preparation and bank authorization
Once an invoice passes three-way matching, duplicate checks, and exception handling, it is posted to the ledger. Posting accrues the expense and registers the liability in the vendor balance. To handle high volumes, finance teams can configure automated tasks to post vendor invoices. This allows the system to handle accounting recognition.
However, posting an invoice is strictly an accounting action; it does not move cash. The next phase is payment register preparation. The system aggregates due invoices into a structured file based on payment dates. Finance operations managers use vendor open transactions reports to verify balances before finalizing the register.
The final steps are authorization and execution in the bank. An approved invoice and a prepared payment batch do not give a workflow system the authority to send money. The payment register must be exported to the corporate banking portal, where a designated treasury officer reviews the total outflow. They verify vendor bank details against master data and apply their signature to authorize the transfer. Payment execution remains under the control of authorized human personnel.
Sources: [2]
Action checklist
- Configure organization-approved variance tolerances for automatic invoice matching.
- Route matching invoice numbers and supplier identities to duplicate review, accounting for corrected invoices and adjustments.
- Define separate authorities for commercial approval, register preparation and bank authorisation.
- Ensure access to an electronic contract database for verifying disputed charges.
Questions and answers
Why can't the system automatically pay an invoice after manager approval?
Commercial approval often only confirms the receipt of goods. The process requires separate invoice validation, payment register preparation, and final authorization by the treasurer in the bank.
What to do if the invoice contains unexpected delivery charges?
The invoice is blocked due to unallocated charges. The financial controller must check the contract terms and allocate these costs before posting the document.
How does the system prevent double payment of a single invoice?
The software checks the combination of the invoice number, vendor identity, and other attributes, blocking potential duplicates until an operator verifies them.