Solutions
Three systems, and what each one changed
Client identities are withheld. One card per system, with the workflow, the situation and a worked example folded in underneath for anyone who wants them.
A payables tool cannot see your sell price, so it cannot see what an overcharge costs you.
One supplier invoice, measured two ways · illustrative figures
Same invoice, two systems. A payables tool cannot see the sell price, so it cannot see the damage. Because the job owns both commitments, the overcharge reports as margin rather than as a percentage of a purchase order, and the approver is shown the number that actually changes the decision. no standalone AP or AR tool can produce this
The job is the root record, not the sales order, so it owns both the client commitment and the supplier one. Buy and sell sit together, and margin is a live number rather than a monthly archaeology exercise.
The situation, the workflow and the screen
The situation
A business that buys on one side and sells on the other, with margin in between. Packaged ERP assumes a company selling its own goods, so on every piece of work the two halves lived in separate documents.
Where it broke
- A supplier invoicing above purchase order breached an accounts payable tolerance, and nobody could see it was eating a job already priced to the client
- Client side and supplier side moved on separate clocks, so a delayed supplier receipt did not stop a client invoice going out
- Every margin question was answered in a spreadsheet a month later, after the pricing decision it should have informed
What we changed
Each piece of client demand creates a paired commitment, client facing from quote to cash and supplier facing from sourcing to payment, and the job owns both. Underneath, nothing writes to a record directly: the application holds no insert, update or delete rights, and every change passes an approval gateway enforcing a second person rule and a role floor per target. Ledgers are append only and hash chained, so a correction is an opposing entry rather than an edit.
Your payables tolerance says 6 per cent. Your margin says 21 per cent. Which one should stop the payment?
A standalone payables tool sees a 6.1 per cent breach against a purchase order and routes it as a tolerance exception. It cannot see anything else, because it does not know the sell price. Here the buy and the sell sit on the same record, so the same event reports as a fifth of the margin on a job already priced to the client. One of those numbers gets an approver's attention. The other gets approved.
Invoices keyed by hand, so cost per invoice never falls when volume rises.
What changed, and what deliberately did not
The two rows that did not change are the point. Intelligence removed the keying and the matching, not the control. every business case is built from your own cost base
AI reads the document, a deterministic rules engine performs the match, and two named human gates hold the posting and the payment. The ERP is untouched.
The situation, the workflow and the screen
The situation
A finance operation keying supplier invoices by hand into an established ERP and performing three way match manually. The design rule: intelligence reads but never writes, and everything runs inside the client's own cloud tenancy.
Where it broke
- Cost per invoice was fixed to headcount, so volume growth was hired for rather than absorbed
- Match evidence lived on a second screen, so approvals were a matter of trust rather than inspection
- Vendor queries were answered from memory, which is slow when it works and expensive when it does not
What we changed
Documents arrive and are de-duplicated by hash. Intelligence extracts header and line detail into a structured record, read only. A payables reviewer verifies and pushes with one click, and only that human action creates the pre-booking. Purchase order and receipt are retrieved read only, a rules engine matches against per vendor tolerances, and the result either moves to a payment proposal for final human approval or into a reason coded exception queue with a drafted vendor reply that a person sends. Zero retention, no fine tuning, a sandboxed build and an append only audit trail per invoice were in the first drawing.
Moves to the payment proposal with the match evidence attached, so the approver inspects rather than trusts.
Exception queue, reason coded. The drafted supplier reply quotes the actual variance, so the conversation starts at the answer.
Sorting the collections list by age chases the wrong customer first.
The same ledger, worked two ways · illustrative figures
Sorting by age chases the wrong customer first. Ranking by value, age and whether the last promise held puts the 184,200 at the top of the list and takes the disputed 22,140 out of the chase queue entirely, because chasing a dispute is how a receivable becomes a complaint. the ranking rule is configured per portfolio
Chasing became ranked work: value, age and promise history decide the order, the contact is drafted, a person sends it, and a broken promise escalates on its own.
The situation, the workflow and the screen
The situation
A shared service finance operation running receivables and payables across multiple entities and currencies, where process knowledge sat with individuals and reporting was assembled by hand each month.
Where it broke
- Days sales outstanding could be stated but not explained by account, so the board conversation was defensive
- Chasing was effort based rather than value based, and a promise to pay was remembered rather than recorded
- The same procedural question was answered from memory in different locations, differently each time
What we changed
The core processes were brought into one AI assisted application: invoice generation and dispatch, collections cadence, remittance matching and cash application, ageing and DSO reporting, closed loop feedback and escalation on the receivables side; portal submission, three way match validation, vendor onboarding and payables analytics on the other. Across both, a process knowledge agent that answers from the current procedure and cites it, and intelligent ticket routing. Disputed value leaves the collections queue entirely and enters deductions with its reason code.
Which of these customers is late, and which is simply in dispute?
The hatched portion of every bar is disputed value. Chasing it does not collect it, it manufactures a complaint, so it leaves the collections queue and enters deductions with its reason code. Move the slider and effort stops following the sort order and starts following value, age and whether the customer kept the last promise they made. The number a chief financial officer cares about is on the left, and it moves.
Client identities, volumes and outcome figures are withheld. Every number on this page belongs to a worked example and is labelled illustrative in its own header.
Second line of IP
Products, built from the same parts
Consulting is the practice. Products are where the reusable components get proven at multi tenant scale.
JobLens
Multi tenant AI SaaS with row level isolation, metered credits, an admin console with an activity log, document parsing and a voice rehearsal mode. Cost per action is measured rather than assumed, and model routing was changed on the evidence to hold margin.
The honest limit is in the product. It prepares. It does not apply on anyone's behalf and does not claim confirmed vacancies.
Scheduling and billing
Specified, not built, and listed because we would rather show a pipeline honestly than imply a portfolio. Agents, students, rate cards, sessions and attendance as a data model, hard conflict detection with priority tiers, and cancellation treated as an explicit billable state.
What carries between builds
- The approval gateway, second person rule and role floors
- Operation functions as the only write path
- Append only, hash chained ledgers
- State machines held as data
- Two gate document to decision pipeline
Your process is not on this page.
Most are not. The pattern usually transfers even when the industry does not, because the hard part is the control design rather than the domain.