Procure to Pay
Carry one purchase requirement from request to supplier payment without losing why it was raised.
Keep the approved need connected as buying, receipt, supplier bill and payment move through different people and teams.
Owner path
- Requester
- Approver
- Buyer
- Stores
- Accounts
The work changes hands. The requirement should not.
One requirement. Five owners.
The process changes hands four times. Each team should receive the context it needs from the team before it.
The record that movesOne purchase requirement
OwnerRequester
- RequestA person does thisSomebody needs something, and says what and why.
Handoff
- What moves
- Purchase requirement and amount
- What must be true
- Request submitted
- What changes hands
- Approver decides whether it can proceed
- What can stop it
- Not enough information to decide on
OwnerApprover
- ApprovalA person decidesApproved, sent back, or approved for less.
Handoff
- What moves
- Approved requirement
- What must be true
- Relevant approval completed
- What changes hands
- Buyer becomes responsible for purchasing
- What can stop it
- Sent back, or approved for a different quantity
OwnerBuyer
- Purchase or POA person does thisSupplier chosen, commercial terms settled.
Handoff
- What moves
- Purchase context, and the PO where one is used
- What must be true
- Supplier order has been placed
- What changes hands
- Stores or receiving checks what actually arrives
- What can stop it
- Supplier confirms a different date or quantity
OwnerStores
- Receipt or GRNA business event happensWhat actually arrived, checked against what was ordered.
Handoff
- What moves
- Purchase and receipt context
- What must be true
- Receipt is recorded
- What changes hands
- Accounts can review the supplier bill against what was bought and received
- What can stop it
- What arrived and what was ordered do not match
OwnerAccounts
- Supplier billA person does thisRead and prepared, then reviewed.
- PaymentA person decidesAn accounts decision, in the normal process.
It starts as a need with a reason behind it, and it should end as a bill somebody can check rather than guess at. Four handoffs in between, and the requirement is the one thing that has to survive all of them.
Approval should hand the buyer a usable requirement.
How a request is raised, what triggers an approval and who gets notified is the Business Automation pillar’s subject, and it follows this same purchase request all the way through. This page starts where that one stops: what the buyer actually receives.
Example requirement
- Requester
- Plant team
- What is needed
- The requirement, in the requester’s words
- Amount
- ₹85,000
- Needed by
- Where a date was recorded
- Reason
- Why it was raised at all
- Approval
- Approved by Anita
The reason is the field that goes missing first, and the one the buyer needs most when a supplier offers something slightly different.
The ₹50,000 threshold in that example is one company’s rule. Approval limits are configured, not universal, and some requirements need no approval at all.
- Business AutomationHow the request, the threshold and the approval work. This same ₹85,000 request, in full.
- Alerts & RemindersTelling the right person a condition or a date needs attention.
Buying is its own job, and it needs the context.
An approved requirement is not yet a purchase. Somebody has to turn it into a supplier, a price and a date.
The purchase order should point back to the approved need.
Otherwise the only thing connecting a supplier commitment to the reason it was made is somebody’s memory of the conversation.
- Which approved requirement it came from
- Who approved it, and for what amount
- What the requester originally asked for
- Which supplier was chosen, and on what terms
Whether the PO is created automatically or by a buyer depends on the system and process in use. The important part is that it can still be traced to the approved requirement.
Receipt is a business event: what arrived, against what was ordered.
This is the first point in the journey where the business finds out whether what it bought is what it is getting.
A business event happens
- Ordered
- Arrived
- Difference
Short quantity
Less arrived than was ordered.
Damaged item
It arrived, and it is not usable.
Different item
Something came, but not the thing that was bought.
Recording a receipt is not the same as having accurate stock. Whether and how stock is updated depends on the systems in use, and a recorded receipt does not guarantee what is on the shelf.
The supplier bill should arrive with its context attached.
A bill on its own is a number and a supplier name. A bill connected to a purchase and a receipt is something somebody can check.
- Which purchase it relates to
- What was received against that purchase
- Which approved requirement started it
The bill can be read and prepared as a draft record. Validating it and posting it still happen in your normal accounting process — nothing here posts an accounting entry or approves a payment.
- Document Data CaptureTurning a supplier bill into a draft record instead of retyping it.
- Document UnderstandingReading what a document actually says.
Keep mismatches visible instead of resolving them quietly.
Every one of these is a question for a person. The workflow’s job is to make sure the person can see it.
Purchase order against received quantity
What was ordered and what arrived are not the same.
Receipt against supplier bill
The bill charges for something the receipt does not show.
Price difference
The billed price is not the price the purchase was placed at.
Missing reference
The bill arrives with nothing on it that connects it to a purchase.
Comparing purchase, receipt and bill is something a process can be set up to do. It is not automatic, it is not universal, and it is not a guarantee that the three agree.
Payment is the final accounts step, not an automatic outcome.
After the bill has been reviewed in the normal accounting process, payment remains an accounts decision and action. This workflow only keeps the purchase context connected to it.
- No payment is made by this process
- No accounting entry is posted by this process
- There is no bank reconciliation and no live bank feed
- Accounting figures are as current as the system they come from, not real-time
Where the detail lives
This page is about the movement between five teams. Each page below owns one part of it.
- Business AutomationThe request, the threshold and the approval, in full.
- Alerts & RemindersTelling the right internal person that something needs attention.
- Supplier Quote ComparisonCompare quotations where the requirement is worth quoting out.
- Document Data CaptureCapture a supplier bill as a draft record.
- Document UnderstandingRead what a document says, and mark what is uncertain.
Where does your purchase context get lost?
Tell us how a purchase request becomes a paid supplier bill today, and we will help you find the handoff that drops the most.