Most teams find out what they committed to when the invoice arrives. This puts the control at the requisition, the amendment and the dock.
Eight stages. Three of them can stop the order.
Lines with quantities, unit prices, GL coding and a need-by date — so an approver sees what's being bought and when it's expected, not just a total.
If your chart of accounts demands a department or a project, the requisition can't be submitted without them.
The same engine that routes bills routes requisitions — by amount, department, project or category.
The conversion claims the requisition atomically. An impatient double-click cannot produce two POs — a failure that usually surfaces only when the second invoice arrives.
No login, no account to create. They accept with a date, request a change, decline with a reason, send an advance ship notice, or message the buyer — and it lands on the order, not in someone's inbox.
Partial receipts keep the order open for the balance. Over-receipt is checked against a limit you set.
One bad line shouldn't reject a delivery, and one good line shouldn't accept it. Rejected goods raise a debit memo automatically — the credit you're owed exists immediately, not from memory.
The order and receipt are the same records the match gate reads — nothing exported, nothing re-keyed. Anything received but not yet billed sits in the GR/IR ledger for period end.
A requisition missing its department or project creates work for someone else later — usually the Controller, usually at close, usually with the vendor already paid. The fix isn't a reminder email. It's making the field impossible to skip.
Maintenance parts, packaging, contract labour — ongoing arrangements with a negotiated rate. Run as one-off POs they lose the ceiling; run in a spreadsheet they lose it quietly.
Why the forecast matters. An AP aging report describes obligations that already exist — by then the decision is made. Open commitments answer the more useful question: what have we promised that hasn't reached AP yet.
Every system has to answer this: when a buyer edits an approved PO, does it need approving again? Say "always" and approvers stop reading. Say "never" and the approval meant nothing. PayCure judges the direction of the change.
| Change | Result |
|---|---|
| Unit price increased | Re-approval required |
| Quantity increased | Re-approval required |
| Payment terms shortened | Re-approval required |
| Vendor changed | Re-approval required |
| Unit price reduced | Approval retained |
| Payment terms extended | Approval retained |
Superseded versions are kept. An amended order doesn't overwrite its predecessor. When an auditor asks what was approved in March — not what the order says today — the March version is still there.
The gap between issuing a PO and hearing back is where delivery surprises are born. The supplier emails a buyer to say the date slipped; the buyer is on leave; the warehouse still expects the original date. Requiring a login guarantees small suppliers never reply at all.
A requested price rise is an amendment. Accepting one sends the order back through approval automatically — the vendor cannot negotiate around your controls by asking nicely.
Over-receipt is how companies pay for goods they never agreed to buy — and it defeats three-way matching entirely, because the invoice for 520 matches the receipt for 520 perfectly. The control has to sit at the dock.
Fifteen fraud signals, a match gate that blocks, and three checkpoints between approved and paid.