An ERP procurement module runs the procure-to-pay cycle: a staff member raises a purchase request, it is approved against budget and authority limits, a purchase order goes to the supplier, goods or services are received, and the supplier invoice is matched to the order and the receipt before payment. Each step is recorded, so every payment can be traced to an approved need.
Procurement is where weak controls cost money directly: duplicate payments, invoices for goods never received, prices that drift from the agreed contract, and changed bank details that redirect payments. This guide covers the cycle, the approval matrix, supplier master controls and three-way matching, with checklists you can use in a specification or a vendor demo.
What are the steps in the procure-to-pay cycle?
The procure-to-pay (P2P) cycle has seven steps, and a good ERP records an owner, a status and a timestamp for each. Skipping steps is sometimes acceptable, but the system should make the skip visible.
- Requisition. A requester raises a purchase request with item or service, quantity, cost centre or project, and needed-by date.
- Approval. The request routes by amount, category and cost centre to the right approvers, with a budget check.
- Sourcing. For new or larger purchases, buyers collect quotes or use a framework agreement or contract price.
- Purchase order. The approved request becomes a purchase order with agreed price, terms and delivery address, sent to the supplier.
- Receipt. The warehouse records goods received, or the requester confirms services delivered, against the order lines.
- Invoice matching. The supplier invoice is matched to the order and the receipt; exceptions go to a queue.
- Payment. Matched, approved invoices are scheduled for payment according to terms and cash position.
If you need a procurement module shaped around your own approval rules and categories, our ERP development service builds individual modules, and the rules engine behind them draws on our workflow automation work.
How should an ERP approval matrix be designed?
An approval matrix sets who must approve a purchase based on its value, category and cost centre. Design it as data the finance team can maintain, not as rules hard-coded by a developer.
Illustrative approval matrix (hypothetical thresholds, set your own):
| Purchase value | Standard category | Capital expenditure | IT and software | Approvers |
|---|---|---|---|---|
| Up to the team limit | Budget holder | Budget holder plus finance | Budget holder plus IT | 1 to 2 |
| Team limit up to department limit | Department head | Department head plus finance | Department head plus IT | 2 |
| Department limit up to executive limit | Department head plus finance controller | Finance director | Department head plus IT plus finance | 2 to 3 |
| Above executive limit | Managing director or CEO | Board or committee | Managing director plus IT | 3 or more |
Rules that make a matrix hold up in practice:
- Approve the total, not the line. Splitting a large purchase into several small requests to avoid a threshold should be detectable: flag requests from the same requester and supplier within a short period.
- Delegation with dates. Approvers going on leave delegate for a fixed period, recorded in the system.
- No self-approval. A requester cannot approve their own request, even if they hold the authority level.
- Budget check. Show remaining budget at approval, and decide whether over-budget requests block or escalate.
- Re-approval on change. If price or quantity rises above a tolerance after approval, the order goes back for approval.
Our approval workflow design guide covers escalation, parallel approval and audit trails in more depth.
What controls belong on the supplier master?
The supplier master record is a common target for fraud and a common source of duplicate payments, so changes to it need the strongest controls in the module.
Supplier master control checklist:
- Segregation of duties: the person who creates or edits a supplier cannot approve purchase orders or release payments to that supplier
- Bank detail changes require a second person to approve, with the change logged
- Bank detail changes verified by calling the supplier on a number already on file, never one from the change request
- Duplicate checks on name, tax registration number and bank account when creating a supplier
- Mandatory fields: legal name, tax number, address, payment terms, currency, contact
- New suppliers blocked from payment until onboarding is approved
- Dormant suppliers reviewed and blocked periodically
- Full change history visible to auditors
These are general internal-control practices rather than any one regulation; your auditors may require more.
How does three-way matching work in an ERP?
Three-way matching compares three documents before an invoice can be paid: the purchase order (what was agreed), the goods receipt (what arrived) and the supplier invoice (what is billed). If quantities and prices agree within set tolerances, the invoice is approved for payment automatically.
| Match type | Documents compared | Typical use |
|---|---|---|
| Two-way | Purchase order and invoice | Services, subscriptions, low-risk items with no physical receipt |
| Three-way | Purchase order, goods receipt and invoice | Stock and physical goods; the usual default |
| Four-way | Adds an inspection or quality acceptance | Regulated or quality-critical materials |
Illustrative example (hypothetical figures): a purchase order is for 100 units at 12.00 each. The warehouse receives 96 units. The supplier invoices 100 units at 12.30.
- Quantity: invoice 100 against received 96. The ERP should only allow payment for 96, or hold the invoice.
- Price: 12.30 against 12.00, a 2.5 percent difference. If the price tolerance is lower, the invoice goes to the exceptions queue for the buyer.
- Outcome: the buyer asks the supplier for a credit note for 4 units and confirms whether the price increase was agreed. Only then is the invoice released.
Design decisions to agree:
- Tolerances by percentage and absolute amount, per category, set by finance.
- Partial receipts and partial invoices matched line by line, not order by order.
- Exceptions queue with an owner, reason codes and ageing, so held invoices do not miss payment terms.
- Non-PO invoices (utilities, rent) handled through a separate approval route, not forced through the match.
- Invoice capture. Many teams read supplier invoices automatically; our guide to intelligent document processing covers how that works and where people still need to check.
Stock receipts also update inventory and its valuation, which our guide to the ERP inventory management module explains.
How should services and non-stock purchases be handled?
Services and non-stock purchases follow the same cycle, but the receipt step is a confirmation by the requester rather than a warehouse booking. Without that confirmation, three-way matching has nothing to match against.
- Service confirmation: the requester or project manager confirms the work delivered, in full or in part, against the order lines.
- Blanket orders: for recurring supplies or services, one approved order with a value or period limit, called off as needed, avoids a new approval for every small delivery.
- Contracts and frameworks: agreed prices held in the system so order lines pick them up automatically, and invoices are checked against them.
- Coding at request: cost centre, project and account are set on the request, so commitments appear in budgets as soon as the order is approved.
Which procurement mistakes should you design out?
Most procurement problems come from a small set of process gaps that the system can prevent.
| Mistake | Effect | Design response |
|---|---|---|
| Orders raised after the invoice arrives | Approvals become a formality | Report and limit retrospective orders; require a reason |
| Receipts not recorded | Invoices pile up in the exceptions queue | Mobile or simple receipt screens; reminders to requesters |
| Duplicate invoices | Paying twice | Check supplier, invoice number, date and amount on entry |
| Tolerances set too wide | Price drift passes unnoticed | Set by category and review the variance report |
| Approvers approving from email without context | Rubber-stamping | Show budget, history and quotes on the approval screen |
What reports should procurement produce?
Procurement reporting should show what is committed, what is stuck, and whether controls are working.
- Open purchase orders and commitments by cost centre and project, against budget
- Requests awaiting approval, with ageing by approver
- Invoices in the exceptions queue, with value and reason
- Spend by supplier and category, and spend outside contracts
- Supplier performance: on-time delivery, quantity and price variances
- Control reports: supplier bank changes, self-approval attempts, possible split purchases
Project-based businesses also need commitments by project, covered in our guide to ERP project accounting.
When is an ERP procurement module not the right approach?
A full P2P module is too heavy when purchasing is low in volume or already well handled.
- Few suppliers, low volume: an approval step in the accounting package may be enough.
- Spend mostly on cards: a spend management tool with card controls may fit better, integrated with the ledger.
- Large indirect spend with complex sourcing: a dedicated source-to-pay suite may suit tendering and contract management, with the ERP handling orders, receipts and payables.
- No receipting discipline: three-way match fails if nobody records receipts. Fix that before you automate the match.
How to start
Collect your current purchasing policy, authority limits, supplier count, monthly invoice volume and the most common reasons invoices are held today. Our ERP RFP template includes procurement requirements you can adapt. When you are ready, discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, and purchase requests with approvals are a natural first module because the benefit is visible quickly.