Fintra Workflow
Procure to pay, with a guard on the money
Procure to Pay
Example figures- BILL RUN
- 38 bills
- $412,900
- MATCHED
- 36 clean
- 3-way
- GUARD
- 1 hold · 1 block
- this run
- 1 · PO issued + approved
- budget checked
- 2 · Goods receipt
- qty matched
- 3 · Bill · 3-way match
- PO = GR = invoice
- Ineos · bank account changed
- BLOCK · verify payee
- Acme · 12% over PO
- HOLD · needs approval
- 4 · GL posting + sealed evidence
- AP / expense
From a PO to a paid bill, matched and sealed
Procure to pay is where money leaves the building, so it is where a guard matters most. Fintra runs the PO, the goods receipt, the bill, the match, and the payment on one ledger, and puts a guard on the run itself: each payment is scored and can be allowed, held for approval, or blocked outright, with the reasons attached. The classic fraud pattern, a supplier bank-account change slipped in just before a large invoice, is exactly what the guard is built to catch.
The four governed steps
1 · Purchase order
A PO is raised and approved against budget, so the commitment is visible before anything is ordered.
2 · Goods receipt
Receiving records what actually arrived, which becomes the middle leg of the match.
3 · Three-way match
The bill is matched against the PO and the goods receipt. Quantities and amounts have to agree within tolerance or the bill is held.
4 · Guarded bill pay
The payment run scores each bill and returns allow, hold, or block, catching bank-change and over-PO cases, then posts AP and expense to the GL with the decision sealed.
Allow, hold, or block, with the reason attached
| Signal | Verdict | What happens |
|---|---|---|
| Clean match, known payee | Allow | Queued to pay, draft-first for approval |
| Amount over PO tolerance | Hold | Routed for a human approval with the variance shown |
| Payee bank account changed | Block | Stopped until the new details are verified out of band |
| Duplicate invoice number | Hold | Flagged as a possible double payment |
Draft-first, sandbox by default
- The three-way match and the tolerance logic are real and deterministic.
- The guard scores every payment and returns an explainable allow / hold / block with the reasons, including a bank-change catch.
- GL posting for AP and expense is real; the evidence is sealed at decision time.
Questions people ask
What is a procure-to-pay workflow?
It is the path from a purchase order through a goods receipt, a bill, a three-way match, and a payment. Fintra runs it on one ledger and puts a guard on the payment run that can allow, hold, or block each bill with the reasons attached.
What does the three-way match check?
It matches the bill against the purchase order and the goods receipt so that quantities and amounts agree within tolerance. If they do not, the bill is held for review rather than paid.
How does the guard catch payment fraud?
It scores each payment and returns allow, hold, or block. A supplier bank-account change just before a large invoice, an amount over the PO tolerance, or a duplicate invoice number each trigger a hold or block with the reason shown, so the payment stops before funds move.
Does it pay vendors automatically?
No. Guarded autonomy is draft-first: the guard recommends and can gate, but a human approves before money moves, and the money rail is sandbox-by-default until you wire a live provider. The guard decides and records rather than paying on its own.
How does this help with an audit?
Each verdict and approval is sealed as it happens, so the AP evidence builds itself. When an auditor asks who approved a payment and why, the record is already attached to the bill.
Keep reading
Guides
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
See a whole flow run on one brain
Book a walkthrough and watch a lead, a hire, or a bill move end to end, governed and sealed at every step.