A lorry backs up to the goods-in door with 70 machined housings against a purchase order for 100. Within the hour three people will each ask what that delivery means. The storeman wants to know how many to book in, the production planner how many can go to the line this afternoon, and the buyer how many are still to come and whether to chase the supplier. A week later finance will ask a fourth question when the supplier’s invoice arrives.

One number cannot answer all of them. Procurement software exists to keep those answers apart while keeping them attached to the same purchase. The purchase below is illustrative, and its arithmetic runs through to the invoice and a rejection.

The records a purchase passes through

A purchase produces a chain of related records. Each asserts something different, and a different person is responsible for it.

A requisition, or purchase request, is someone in the business saying they need something. It carries the item, the quantity, the reason and whatever approval context the business uses, such as a budget holder or a spend limit. It commits nobody to anything yet.

An approved purchase order is the business committing to buy a quantity at agreed terms from a supplier. The buyer raises it and whoever holds the authority approves it.

A goods receipt records what physically arrived against that order. The goods-in team asserts it, on the evidence of a count at the door. It says nothing about whether the goods are any good.

An acceptance, sometimes called a quality release, decides what may be used. Whoever the business trusts to inspect asserts it, on the evidence of whatever check the material requires: a dimensional check, a certificate of conformity or simply a second count. Accepted stock can enter usable inventory. Held stock is physically present and cannot be drawn. Rejected stock arrived, failed, and is now the subject of a return or credit decision.

A supplier invoice is the supplier’s claim for payment. The supplier asserts it. The business judges it against the receipt and the acceptance.

These are related records, not stages of one status. A receipt is a new record pointing back at the order, and when a system collapses the two into a single status field the quantities start standing in for each other.

Ordered, received and outstanding

A purchase order is a commitment at a quantity and terms, and suppliers routinely satisfy commitments in parts. The outstanding quantity is the ordered quantity minus what has been received. It must stay visible until the supplier delivers the balance or the business cancels it.

In the example, goods-in records 70 received against the order for 100 and outstanding drops to 30. The buyer needs that 30 to decide whether to chase, wait or cancel. If someone re-orders it because the balance disappeared from view, the business ends up with 130 housings.

Arrived and usable are different facts

Some materials go straight to the shelf. Others need inspection, certificates, quarantine or a count check before anyone may draw them, and which ones do is a business rule that differs by material, by supplier and sometimes by batch.

Inspection looks at the 70 housings and accepts 65. Five are held for a dimensional check. At that moment production may draw 65, the buyer sees 30 still to come and 5 uncertain, and the warehouse shows 70 physically present of which 5 cannot be used.

The invoice is a claim to be judged

The same week the supplier invoices for 70. The invoice is the supplier’s account of what they shipped. The operational record is the business’s account of what it received and accepted: 70 received, 65 accepted, 5 held.

What the business does with that is its own finance policy. It might pay 70 and pursue any shortfall later, pay 65 and query 5, or wait for the check to finish. Some businesses require all three records to agree before paying; others do not. The operational system supplies the evidence with the quantities intact, and the finance system applies the policy. Our guide to finance and operations systems explains how the operational record and the ledger relate without becoming one system.

Rejection attaches to the order and keeps the history

The following week the 5 held housings fail the check. The rejection is recorded against the same order, and the table shows what changes and what does not.

Received stays at 70, because 70 did arrive and that remains true as history. Accepted stays at 65, held drops to 0 and rejected becomes 5. The commitment of 100 and the 30 outstanding are untouched. The invoice row changes no operational quantity either, because an invoice is not evidence of what arrived. The business now decides about the 5: ask the supplier to replace them alongside the outstanding 30, or return them for a credit and reduce the commitment. Either is a new record with its own approval, and neither rewrites the rows above.

In a system that merges the records, the same purchase goes wrong in predictable ways. If booking in 70 had closed the order, the 30 would have vanished until the line ran out. If acceptance had been assumed at receipt, all 70 would have been usable from the moment they were booked in, and production could have consumed the 5 before anyone measured them. A rejection recorded by editing the receipt down to 65 destroys the record that 70 arrived, so the invoice for 70 can no longer be judged against anything.

Each quantity in the table has one owner and one kind of evidence. The buyer and the approver change ordered, through an amendment or cancellation. Goods-in changes received, on a physical count. The inspector changes accepted, held and rejected, on the check the material needs. Outstanding is derived and nobody edits it. A manager who can say this for each figure in their own business has most of the specification for the software they need.

What to require from procurement software

Receipts must attach to the order without closing it, acceptance must be a separate step with its own quantity, held stock must be visible and impossible to draw, and a rejection must be recorded without erasing the receipt. The evidence for the invoice decision must reach finance with the order, the receipt and the acceptance identifiable.

The process must be changeable without redesigning the receiving step. Adding a material to the inspection list, raising an approval threshold or changing who releases a batch should change the rule and the screens together. A feature list will not tell you whether a system can do this. Ask how the last change to an inspection rule was made.

Where Keel fits

Keel is an operations platform shaped around how a business buys, receives and accepts material. In the example, that means the request captures the approval context the business uses in practice. The goods-in screen records what arrived against the order and nothing else. A guided check releases only the quantity the business’s rule allows and shows the held and rejected quantities to the planner and the buyer. The buyer’s view keeps the 30 outstanding until the business decides otherwise. When the business changes which materials need inspection or raises an approval threshold, the rule and the screens change together and the acceptance step stays explicit.

Keel supports tailored operator tools, workflows that combine human steps with processing, and business rules expressed in code. An implementation of this example would need to define approval limits, the relationships between order, receipt and acceptance, the quantity checks, the acceptance logic for each class of material, and the handover of receipt and acceptance evidence to the finance system, including external identifiers, duplicate handling and what happens when an update fails. Those need to be built and tested. Keel leads the implementation and agrees the handover with your team.

Keel is not an accounting system and not a procurement suite. If your existing ERP purchasing module already keeps ordered, received, accepted and outstanding apart, and your people can run the process reliably, improving that process is enough. If the problem is sourcing, contracts or budget control, a dedicated procurement or spend-management suite is the better answer. Keel is the right conversation when the business needs its own receiving and acceptance rules, and the operator experience around them, to evolve together while staying connected to the finance system it already runs.

Once stock is accepted it enters the stock cycle covered in our inventory management process guide. If you would like to walk through one purchase from request to acceptance, including how your team decides what enters usable stock and what finance needs from that decision, talk to Keel about your purchase-to-acceptance process. Bring one order that was delivered in parts.