Mapping Purchase-to-Pay from Request to Invoice

Follow the commitment, not just the invoice

Purchase-to-pay connects a business need to an authorized order, evidence of receipt, a supplier invoice and a controlled payment. A process map that starts when accounts payable receives the invoice begins too late to explain who committed the company to buy. The useful design follows both the documents and the responsibility for each decision.

This article helps procurement managers and finance teams prepare an ERP process workshop. It uses a hypothetical equipment purchase to expose common handoffs. The same principles need adaptation for services, subscriptions and project purchases; a physical goods receipt is not meaningful evidence that a consulting milestone has been delivered.

Start with a request that can be evaluated

A requisition should explain the need, specification, required date, quantity, expected cost and budget owner. Decide which purchases require quotations and how approved exceptions are recorded. Urgency should change the escalation route where appropriate, not erase the need to establish authority and evidence.

Select or onboard the supplier through a separate controlled process. Payment details are sensitive: accepting a changed bank account simply because it appears on an invoice creates an avoidable risk. Use the business's approved verification procedure and an independently maintained contact route. An ERP approval button cannot establish that a bank-account request is genuine.

Make the purchase order an explicit commitment

The order should capture approved lines, prices, units, delivery terms, charges and the relevant commercial reference. Decide who may confirm or amend it. If an amendment changes the financial commitment, define whether it must return for approval. Preserve version history so an invoice can be matched against the terms that actually applied.

In the example, twenty devices are ordered but only twelve arrive. The receiving team records the twelve received, any damaged units and the delivery reference. It must not mark the entire order received merely to allow finance to process an invoice. The remaining quantity needs an explicit status: outstanding, cancelled or replaced through an approved change.

Match invoices against the right evidence

For goods, a common control compares invoice price with the order and invoiced quantity with receipt evidence. Microsoft Dynamics documentation describes two-way and three-way matching as product-specific mechanisms for these comparisons. Configure the policy for the transaction type, including treatment of freight, discounts, tax and partial invoicing.

In the example, an invoice for all twenty devices should create an exception if only twelve were accepted and policy requires receipt matching. The correct response may be to obtain a corrected invoice, wait for a further receipt or authorize a documented exception. Fabricating a receipt to clear the exception hides the unresolved commercial position.

Services need their own acceptance model

A maintenance visit, design deliverable or recurring subscription does not necessarily produce warehouse stock. Define who confirms delivery, which evidence is required and how partial performance is handled. Link approval to a service period or milestone so the same evidence cannot accidentally support repeated invoices.

Also decide how credit notes, returns and disputed invoices affect the order and supplier balance. A process that handles only the first invoice can leave liabilities or commitments open after a refund. Give exception queues an owner, target response and an escalation rule; storing a document in a holding status is not the same as resolving it.

Separate invoice posting from payment release

An approved invoice records a liability; it does not by itself establish that the correct payment should be sent now. Payment processing should consider due date, holds, available authorization and verified beneficiary information. Reconcile the bank result, including rejected or returned payments, rather than assuming that generating a file completes the obligation.

Use individual accounts and distinguish supplier maintenance, receipt confirmation, invoice processing and payment release. Smaller teams may need documented compensating review, but shared credentials make even that review unreliable. Maintain a trace from request to order, receipt, invoice and payment without giving every participant unrestricted access to all financial data.

Run one complete transaction and its exceptions

• Request goods, reject missing specifications and resubmit the corrected version.
• Approve an order, amend its quantity and verify renewed authority.
• Receive a partial delivery, reject damaged goods and record a later return.
• Submit a duplicate invoice and an invoice with a price discrepancy.
• Process a service invoice with documented acceptance rather than a fictitious stock receipt.
• Reject a payment, resolve its cause and verify that retrying does not pay twice.

Measure unmatched invoices, overdue exception queues and elapsed time between receipt and posting. Investigate reasons rather than optimizing only the number processed each day. A practical first improvement is to map one purchasing category with procurement, warehouse and finance together. PRAESYNX enterprise software services can help translate that agreed process into software and integration requirements; commercial approvals and accounting treatment require the company's responsible owners.