Invoice Approval Standard Operating Procedure

• Benchmark document: Synthetic Digital Sanctum reference process
• Process owner: Accounts Payable Process Owner
• Version: 1.1
• Status: Approved for product benchmarking only

1. Purpose

This procedure explains how a buyer organisation receives, validates, approves, and posts supplier invoices. It is intentionally synthetic, contains no client information, and is suitable for repeatable product testing.

2. Scope

The process starts when a supplier submits an invoice and ends when the invoice is either queued for payment, returned for correction, rejected for an unresolved control exception, or rejected by an accountable approver.

Payment execution, bank settlement, and remittance advice are outside this procedure.

3. Participants and responsibilities

4. Information and records

The process uses and updates these records:

• Supplier invoice and supporting evidence.
• Preparation result containing validation, matching, coding, and exception outcomes.
• Approval matrix containing delegated financial authority and risk-based routing rules.
• Required approvers, as an ordered collection selected from the approval matrix.
• Approval record containing the required route, decisions, timestamps, comments, and escalation evidence.
• ERP posting record confirming that an approved invoice entered the payment queue.

5. Procedure

5.1 Receive and prepare the invoice

1. The process begins when the supplier submits an invoice to the buyer organisation.
2. The Finance System registers the invoice. This normally takes 60 seconds, with a practical range of 20 to 180 seconds.
3. The Finance System validates mandatory invoice controls using the invoice validation rules. This normally takes 120 seconds, with a range of 30 to 300 seconds.
4. If the invoice is invalid, preparation ends with the outcome Correction required. For the benchmark, assume 8% of invoices take this route.
5. If the invoice is valid, determine whether it references a purchase order. Assume 75% of valid invoices are PO-backed and 25% are non-PO.
6. For a PO-backed invoice, the Finance System performs a three-way match between the invoice, purchase order, and receipt. This normally takes 180 seconds, with a range of 60 to 420 seconds.
7. If the match is within tolerance, preparation is complete. Assume 85% of PO-backed invoices match within tolerance.
8. If the match is outside tolerance, an Accounts Payable specialist resolves the exception. The target is 16 hours. Active elapsed work and coordination normally take 7,200 seconds, with a range of 900 to 28,800 seconds.
9. After exception work, decide whether the mismatch was resolved. Assume 70% are resolved and rejoin the successful preparation route. The other 30% end preparation with the outcome Control exception unresolved.
10. For a non-PO invoice, an Accounts Payable specialist applies the correct account and cost-centre coding. The target is 8 hours. This normally takes 1,800 seconds, with a range of 300 to 7,200 seconds, after which it rejoins the successful preparation route.
11. Successful matching or coding ends preparation with the outcome Ready for approval.

The preparation activity is a contained unit of work within the overall invoice process. At the overall level, use its outcome as follows:

• Ready for approval: continue to approval-route determination. For simulation, assume 88% of all invoices reach this outcome.
• Correction required: Accounts Payable sends the supplier the validation findings and requests a corrected invoice, then closes this process instance as Returned to supplier. Assume 8% of all invoices take this route.
• Control exception unresolved: Accounts Payable sends a control rejection notice to the supplier and internal requester, then closes the instance as Control rejection. This is the default outcome; assume 4% of all invoices take this route.

Sending either external notice normally takes 300 seconds, with a range of 60 to 900 seconds.

5.2 Determine the approval route

1. For an invoice that is ready, the Finance System applies the approval matrix using invoice value, risk, legal entity, and cost-centre attributes.
2. The system writes the ordered required-approver list and opens the approval record. Route determination normally takes 90 seconds, with a range of 30 to 180 seconds.
3. Decide whether human approval is required. Policy auto-approval is permitted only when the approval matrix positively confirms eligibility; otherwise route the invoice to human approval as the default. Assume 60% require human approval. The other 40% qualify for policy auto-approval and continue directly to approved posting.

5.3 Obtain human approval

1. When human approval is required, each person in the required-approver list reviews the invoice in order, not in parallel. Use two approvers as the benchmark simulation cardinality.
2. Each review confirms business purpose, supporting evidence, budget availability, and delegated financial authority. The approval activity has a 48-hour SLA. Normal elapsed time is 64,800 seconds, with a range of 1,800 to 345,600 seconds.
3. If the 48-hour SLA expires before the normal review is completed, cancel that outstanding review and send the work to the Finance Manager. The Finance Manager performs a replacement approval with an 8-hour target. This normally takes 3,600 seconds, with a range of 600 to 14,400 seconds.
4. Whether the response comes from the normal approval route or the escalation route, continue with one approval decision.
5. If the approval record says Approved, continue to posting. Assume 90% of completed human approval routes are approved.
6. If it says Rejected, Accounts Payable sends an approval rejection notice to the supplier and internal requester, then closes the instance as Approval rejection. This is the default decision and represents the other 10%. Sending the notice normally takes 300 seconds, with a range of 60 to 900 seconds.

5.4 Post the approved invoice

1. Policy auto-approvals and successful human approvals join the same approved route.
2. The Finance System posts the invoice and its approval evidence to the ERP payment queue. This normally takes 240 seconds, with a range of 60 to 600 seconds.
3. Record the ERP posting result and close the process as Queued for payment.

6. Operating controls

• The supplier remains external to the buyer organisation. Only the invoice, correction request, control rejection notice, and approval rejection notice cross that organisational boundary.
• Accounts Payable, Finance System, Business Approver, and Finance Manager responsibilities must remain separately accountable.
• A process instance closes in exactly one of four states: queued for payment, returned to supplier, control rejection, or approval rejection.
• Retain the detailed preparation record so registration, validation, matching, coding, and exception-resolution outcomes remain auditable.
• When no stated condition is true at a decision, use the route identified above as the default outcome.
• At the 48-hour escalation point, cancel the overdue normal approval. It must not continue in parallel with the replacement Finance Manager approval.
• The timing and probability figures are synthetic analysis assumptions. They do not authorise an actual payment instruction or bank transaction.
• For deterministic Monte Carlo testing, model each stated activity duration with a truncated normal distribution bounded by its stated practical range. Use these synthetic standard deviations: invoice registration 15 seconds; control validation 30 seconds; three-way matching 45 seconds; mismatch resolution 2,400 seconds; non-PO coding 600 seconds; each external notice 90 seconds; approval-route determination 20 seconds; normal approval review 57,600 seconds; Finance Manager replacement approval 1,200 seconds; and ERP posting 60 seconds.
• Retain the procedure scope, exclusions, owner, document version, assumptions, and validation results with any derived process record.

7. Document control

This document may be used for controlled Digital Sanctum product demonstrations and repeatable internal benchmarks. It must never be represented as client evidence, production policy, or approval to execute payments.