Procurement · Finance حالة استخدام
Procure-to-pay in an enterprise
A purchase passes seven stages and several teams before a supplier gets paid.
Most of the time goes into waiting and retyping, not into decisions.
Here is where agents take that work, and where people keep control.
- For
- CFOs, heads of procurement, accounts payable leads and enterprise architects.
- In the demo
- Supplier onboarding and invoice exceptions run in the Falak demo today. The other five stages are design.
On this page
01The process today
Work waits at the handovers, not at the decisions.
A manager needs a new supplier. Procurement, risk, legal and finance each do one part. Weeks later, the first invoice does not match the order, and it waits for someone in accounts payable.
- Request. Requester. Email or ERP form.
- Source and onboard the supplier. Procurement, risk, legal. Waits for documents and sign-offs.
- Purchase order. Procurement, in the ERP.
- Goods receipt. Requester or warehouse, in the ERP.
- Invoice and three-way match. Accounts payable, in the ERP.
- Exception handling. Accounts payable and the controller. Waits for a person to look at it.
- Payment. Finance, from the ERP to the bank.
Every handover is a wait, and every retyped number is a possible error. The decisions are few. Most of the effort is the work around them, and agents can do that work.
What to do next: find the stage where your work waits longest. Often it is stage 02 or 06.
02Where agents fit
Agents prepare and explain. Code checks and calculates. People decide on money, suppliers and exceptions.
Every stage splits the same three ways. Code gives the same answer every time, so it does the checks and the sums. Only the two rows marked demo run on Falak today. The other rows are design.
| Stage | Agent prepares | Code checks or does | Person decides |
|---|---|---|---|
| Request | A complete case | Required fields | Requester submits it |
| Onboard supplier (demo) | The record, with its sources | Duplicates, screening, the write | Procurement approves |
| Purchase order | A draft order | Budget, contract terms | Buyer approves |
| Goods receipt | A match to the order | The receipt in the ERP | Warehouse checks the counts |
| Invoice and match | The invoice, linked to its order | The three-way match | Nobody, if it matches |
| Exception (demo) | The exception type and its policy | Difference, tolerance, correction | Accounts payable approves |
| Payment | A summary of the run | The run in the ERP | Finance releases. Never the agent |
Each action has an autonomy class. It says how far the agent can go without a person:
- A0 reads only.
- A1 prepares, does not act.
- A2 acts within set limits, and the action can be undone.
- A3 waits for a person to approve.
- A4 is for people only. The agent hands the case over.
03One request, end to end
Two demo cases show the full path: a new supplier, and an invoice that does not match its order.
A. Onboard a supplier
A requester asks to onboard Nordwind Industrial Components GmbH. The agent finds no duplicate and a clear screening, and proposes one A3 action. Falak creates supplier SUP-0061 only after a person approves the exact record.
- Requester submits the request. Falak opens a task.
- Agent collects evidence and proposes one A3 action.
- Falak checks the proposal against the rules.
- Approver sees the exact record and approves it.
- Falak checks that the action did not change.
- ERP creates supplier SUP-0061.
- Falak reads it back and closes the task as verified.
The same flow handles the hard cases. "Live" cases are part of the scripted demo. We run the other demo cases on request.
| Case | What happens | Shown |
|---|---|---|
| Karst, a duplicate | The tax id matches SUP-0003. The agent proposes the existing record. Falak writes nothing | On request |
| Orion, a screening match | The policy says a specialist decides. The agent escalates (A4) | On request |
| Helios, a hidden instruction | A brochure asks to email bank details out. Falak denies the email and logs it. Onboarding continues | Live |
| Worker stops mid-write | Falak resumes from its history. The ERP has one Nordwind, with one receipt | Live |
| A change after review | Someone edits the bank account. Falak refuses to run the changed action | Live |
B. Fix an invoice exception
Invoice INV-0042 bills EUR 12,360 against an order of EUR 12,000. Code, not the model, computes the EUR 360 difference, the EUR 240 tolerance and the EUR −360 adjustment. The hold is A2 and needs nobody. The approver sees the exact posting, debit 2100 and credit 5000, and approves the adjustment and the invoice once. This case is in the live demo.
| Case | What happens | Shown |
|---|---|---|
| A duplicate invoice | Hold only. No approval, nothing posted | On request |
| EUR 28,500 difference | Above the EUR 25,000 cap. The agent holds and escalates to the Financial Controller (A4) | On request |
| The ERP reply is lost | Falak checks the ERP by operation id. The ERP holds exactly one adjustment | On request |
| Wrong amount from the model | The model writes −400. Code rejects the proposal before anyone sees it | Eval case |
| Release the payment | The agent has no tool for it, and a rule denies it | By design |
What to do next: take one real case from your queue. Write down who decides and what they need to see.
04Controls that make it safe
Each action has a class, an approver, a record and a plan for failure, all set before the agent runs.
Falak writes every action and its result to an action record (the ledger).
| Action | Class | Who approves | What Falak keeps | If it fails |
|---|---|---|---|---|
| Read and screen | A0 | Nobody | The sources the agent cited | Nothing to undo |
| Create supplier | A3 | Procurement, on the exact record | Approval, receipt, read-back | One key, never a second supplier. Undo blocks it |
| Email supplier | A2 | Always a person. Never with bank details | Every denial | No mail goes out |
| Hold invoice | A2 | Nobody | ERP status, read back | A release undoes it |
| Adjust invoice | A3 | AP Team Lead to EUR 1,000, AP Manager to EUR 25,000. Above that, the controller (A4) | Posting, receipt, read-back | Falak checks the ERP. It never posts twice |
| Release payment | Not offered | People only | Nothing to keep | A rule denies it |
Three more guards apply to every action. Each approval binds to the exact action, so any later change voids it. The kill switch stops an agent at once. The audit log is a chain, so a changed entry shows.
What to do next: write this table for your process before anyone builds.
05Build it on Falak
A team writes one pack per process. The platform supplies everything around it.
A pack holds what is specific to your process: an agent definition with its limits, an approved prompt, one tool per system action, a rule set, schemas, demo data and eval cases. Eval cases are tests that run before each release. Counted in the repository on 25 October 2026:
| Part | Procurement | Finance |
|---|---|---|
| Tools | 6 | 7 |
| Agent definition, prompt, rule set | 1 each | 1 each |
| Demo cases | 6 | 4 |
| Eval cases | 16 | 15 |
| Files, tests not counted | 23 | 26 |
| Lines of TypeScript | about 1,500 | about 2,800 |
The finance pack is larger because it holds the code that computes every amount.
Every pack shares the platform: intake, durable workflow, approvals, tool gateway, action record, audit, knowledge search, registry, kill switch, evals and the workbench. That is about 21,500 lines of TypeScript, plus 16 adapters. In the demo, the finance pack goes live with one restart and no change to the platform core.
What to do next: list your systems, rules and approvers. That list is most of a first pack.
06What to measure
Measure the waits and the errors from day one, before you change anything.
These are measures to track, not results that we report.
- Onboarding cycle time, from request to an active supplier.
- Invoices held for a person, and how long each one waits.
- Exceptions per hundred invoices, by type.
- Approval wait, from the request to the decision.
- Touchless share, the invoices that pass with no human step.
- Duplicate payments caught before any money moves.
Falak keeps a timeline of each task, with every state change and approval, so cycle time and approval wait come from its own records.
What to do next: take a baseline for three of these numbers now.
07Expand from here
The next process reuses most of what the first one built.
These three are design. They are not in the demo yet.
| Next process | It reuses | It adds |
|---|---|---|
| Contract changes | Document search, approvals, supplier record | Contract rules, a contract system tool |
| Risk re-screening | The screening tool, the A4 path, the record | A schedule and re-screening rules |
| Payment-run review | Invoice and order reads, the payment rule | A run summary for the person who releases it |
What to do next: choose the process that shares the most tools with your first one.