The order and the delivery may not match yet
An approved purchase order is not proof that every item has arrived. A supplier may deliver part of an order, split a shipment or issue an invoice before the receiving team has completed its checks. Those differences should remain visible through the payment review.
Consider a fictional order for ten electrical isolators at IDR 2,000,000 each. The approved order value is IDR 20,000,000, excluding any separately agreed tax or charges. Only six units have been received, while the supplier invoice lists ten. The difference needs a decision before that invoice is treated as ready for payment.
Use item and supplier codes consistently
Descriptions help people understand a line item; codes help keep records connected. The purchase request, order, receiving note and invoice review should refer to the same item code and supplier identity. Similar descriptions should not silently become interchangeable products.
| Record | Illustrative quantity | Purpose |
|---|---|---|
| PO-00041 / ELEC-ISO-01 | 10 ordered | Agreed quantity and price |
| GR-00041 / ELEC-ISO-01 | 6 received | Receiving record |
| INV-00041 / ELEC-ISO-01 | 10 invoiced | Supplier claim under review |
Supplier codes should identify the actual party being ordered from. A selected supplier name in a demo is not a substitute for onboarding, banking verification or the controls used by the real business.
Define what happens when a match fails
A mismatch should produce a clear exception with an owner. Possible outcomes include asking for a corrected invoice, receiving the outstanding goods, documenting an approved exception or handling a valid partial invoice. The correct choice depends on the contract and the company's finance rules.
In a simple demonstration, the safest understandable rule is to block progression while the invoice exceeds the recorded receipt. A real implementation may need additional rules for services, tolerances, returns, deposits, tax and multiple invoices.
Keep approval authority explicit
The request value determines which approval route applies under the agreed matrix. Display the required role and record the decision rather than leaving users to infer it from a status label. Approval boundaries, currencies and treatment of split requests need a documented definition.
The authorized person should see the item lines, supplier, amount and reason for the request. A later invoice change should not quietly rewrite an already approved order. Retain the original record and make revisions visible.
Separate payment readiness from money movement
A completed document check can mark an invoice ready for a treasury review. It does not prove that a bank transfer happened. A useful report separates matched documents, approved payment instructions and confirmed payment records.
For an initial implementation, walk one order through request, approval, receipt, invoice and payment recording using sample data. Include a partial delivery and a rejected decision. These exceptions reveal more about the control design than a perfect order that passes every step.
ERP and bank connections require their own access, validation and reconciliation. The browser scenario linked below simulates document decisions only; it does not connect to SAP, validate tax or transfer funds.
Open a fictional scenario, make the decisions and inspect the report.
Open the related scenario ↗