← Back to Work
Process file · Finance
Finance
What’s inside: output checking · access rules
Every line in the bank file checked, not trusted
The question this file answersWhen the payment file leaves for the bank, who has actually checked that every line is an approved invoice?
Fits: finance teams handling 500–5,000+ invoices and receipts a month.
Typical day
What the desk looks like today
Typical pattern, not a measured desk. The finance playbook's AP desk sees 500–5,000+ invoices a month but publishes no count for payment runs. The run is built in a spreadsheet, uploaded to the bank portal, and trusted to contain only approved invoices. It hurts when the approver is away.
What changes
What Monday looks like after
On run day the AP lead opens a short list of lines that failed a check — a changed bank account, a duplicate, an amount that drifted — rather than re-reading the whole file. Treasury still releases the payment, and the log shows which lines were checked and by what rule.
Typical, not a measured client result. Every figure here comes from the playbook source named below.
Invoice
Approval
Match
Bank
Stop
How this file is built
Ardent Partners (2023) and IOFM (2023) measure invoice processing, not payment-run checking, so their 50–70% stays on the AP file and this one carries no percentage. Not a fraud-loss claim.
What we install
What we put in front of the systems you already run
Your ERP and bank portal stay — Oracle, SAP, Dynamics or whatever pays your suppliers today. This is the same three-way checking build as our AP invoice matching, pointed at the run:
- the proposed bank lines are read from the payment file or the ERP proposal
- each line is matched to the approved invoice and to the approval record — amount, vendor, bank details, duplicate
- lines that match are left in the run, and every break appears on one screen with the invoice and the approval next to it, before anything is uploaded.
The upload itself remains yours.
What stays human — and what this will not do
New beneficiaries. Urgent payments. Dual control on release. Anything treasury must own.
Not a fraud-loss claim.
What can go wrong — and what we do about it
If vendor bank details in your master are stale, every line for that vendor breaks and the first runs produce a long review list before it settles. New beneficiaries and urgent payments are excluded by rule and stay under dual control; this build checks the run, it does not release it.
What it costs to get there
The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →
Scoped in the audit — the playbook has no estimate for this exact desk.
This is about you if…
- Is the payment run still assembled in a spreadsheet and checked by eye before upload?
- Are approvals recorded in the ERP or a workflow tool, not only in email?
What does this mean in euros?
That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.
Not a named Aperanda client. Process file · Finance.
Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.
All process files