Forward-Deployed Engineering · Manufacturing · Accounts payable
Case study: supplier invoices, from inbox to posted ledger entry
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedReadiness & Scoping SprintTwo weeks inside your systems; one workflow scoped in writing.
Illustrative results, first 90 days after cut-over, in-scope invoices only:
61%
Invoices posted with no human keying
Before 0%
0.6 days
Median time an exception waits for a person
Before 3.2 days
99.7%
Field-level accuracy of posted entries, weekly audit sample
Before not measured
0, by design
Changed supplier bank details accepted automatically
Before not applicable
Explainer09 sheets
The whole story in about a minute
Nine short scenes, from the invoice pile to the results. Press play, or pick a scene.
View AInvoice pile
Invoices waiting
About 14,000 invoices a month
- Discount lost
Sheet01 / 09
ClockBefore
Every supplier invoice was typed in by hand.
About 14,000 invoices a month, keyed into the ERP by nine people. An invoice took a median of 11 days to post, and early-payment discounts were lost.
- 1.About 14,000 invoices a month
- 2.Nine people keying by hand
- 3.38% of PO invoices needed a chase
At a glance
- Client
- A mid-sized manufacturer of industrial pumps and valves, three plants, one shared finance function
- Workflow
- PO-backed supplier invoices: receive, read, three-way match against purchase order and goods receipt, post to the ERP
- Engagement
- Readiness & Scoping Sprint (2 weeks), then Production Sprint (6 weeks)
- Team
- One named senior forward-deployed engineer, full time. Client side: the AP Controller (owner), an AP systems analyst, a platform engineer, a security reviewer
- Where it runs
- The client's own cloud account and region. No data retained outside it
- Handover
- Runbook executed by the client's team in week six; our access revoked the same day
| Measure | Before | After |
|---|---|---|
| Invoices posted with no human keying | 0% | 61% |
| Median time an exception waits for a person | 3.2 days | 0.6 days |
| Field-level accuracy of posted entries, weekly audit sample | not measured | 99.7% |
| Changed supplier bank details accepted automatically | not applicable | 0, by design |
FDE / 01Case study
01 / 12
In shortNine people keyed about 14,000 invoices a month by hand, and each took a median of 11 days to post.
The finance team received around 14,000 supplier invoices a month. They arrived as PDF attachments in a shared mailbox, as uploads to a supplier portal, and as paper scanned at the plants. Nine people in accounts payable keyed each one into the ERP by hand.
About seven in ten invoices referenced a purchase order. Those should have been simple: find the order, find the goods receipt, check that quantities and prices agree, post. In practice, 38% of them needed someone to chase purchasing or the stores before they could be posted. Price differences, partial deliveries and receipts not yet booked were the usual causes.
- 38%needed someone to chase purchasing or the stores before they could be posted
The cost showed up in three places:
Cycle time. An invoice took a median of 11 days from arrival to posting. Early-payment discounts were lost as a matter of routine.
Risk. Duplicate invoices were found in quarterly reviews, after payment. A supplier bank-detail change was once accepted from an email that turned out to be fraudulent; it was stopped by the bank, not by the process.
People. Month-end meant overtime. The team's most experienced person spent most of her week on exceptions only she knew how to resolve.
FDE / 02Case study
02 / 12
In shortA vendor demo read invoices well, but it never reached the ERP, passed security or had an owner.
A year earlier the company had run a pilot with a document-extraction vendor. On 200 clean, digital PDFs the demonstration was impressive. It never reached production, for reasons that are common rather than unusual:
It stopped at extraction. The pilot read invoices well, but nothing connected it to the ERP. Matching and posting were left for "phase two".
It failed the security review. Invoices would have been processed in the vendor's region. The IT security team, reasonably, would not sign.
It had no owner. The pilot belonged to an innovation budget, not to the AP Controller. When the sponsor moved role, it lost its champion.
Nobody could say whether it was right. Accuracy was reported on the vendor's sample, not on the company's own invoices, scanned paper included.
This is the gap forward-deployed engineering exists for: the model was never the hard part. Access, integration, evaluation, security sign-off and a named owner were.
FDE / 03Case study
03 / 12
In shortTwo weeks inside the finance team, ending in a one-page scope signed by the AP Controller.
The engineer spent the two weeks inside the finance team: two days sitting with AP clerks, a day with purchasing and the stores, and the rest reading systems and data.
What was found:
FIG. 3.1- The ERP exposed an approved import interface for AP documents, already used by an older EDI feed. That meant write-back could go through the same path and the same approvals a person uses, not around them.
- Goods receipts were often booked in the ERP up to 48 hours after the delivery. Many "mismatches" were timing, not errors.
- Around 400 suppliers accounted for most PO-backed invoice volume, in about 60 distinct document layouts.
- Tolerances existed only in people's heads. Different clerks accepted different price differences.
The one-page scope, signed by the AP Controller:
- WorkflowPO-backed invoices from the top 400 suppliers, INR and USD, from mailbox and portal, to a matched and posted AP entry
- Out of scopeNon-PO invoices, credit notes, freight and customs invoices, supplier onboarding
- MetricShare of in-scope invoices posted without human keying, at or above 99.5% field-level accuracy on the golden set
- OwnerAP Controller
- GuardrailsNo change to supplier bank details is ever accepted automatically. The model never decides to post; deterministic rules do
- Exit gateOne week of shadow-run parity, one week live with rollback armed, runbook executed by the client's own engineer
The Controller also wrote down, for the first time, the tolerance bands the team would accept. That single page did more to reduce exceptions than any model later would.
Timeline09 stations
The engagement, stage by stage
Nine stages on one clock, from the invoice pile to ninety days after cut-over. Press play, or pick a stage.
LineStopped
StationOP 10 Invoice pile
ClockBefore
Work instructionOP 10 · 01 / 09
Every supplier invoice was typed in by hand.
About 14,000 invoices a month, keyed into the ERP by nine people. An invoice took a median of 11 days to post, and early-payment discounts were lost.
- About 14,000 invoices a month
- Nine people keying by hand
- 38% of PO invoices needed a chase
FDE / 04Case study
04 / 12
In shortSix weeks: embed, prototype, build, cut over, hand over, with a four-day pause written down.
The four days were the paused clock in week one
W0Scope
What happened
Scope page signed; access requested for mailbox, portal, ERP read replica and import interface
What existed at the end
The signed scope and an access checklist
What happened
Scope page signed; access requested for mailbox, portal, ERP read replica and import interface
What existed at the end
The signed scope and an access checklist
What happened
Repository created in the client's source control; engineer joined AP stand-ups. ERP read-replica access arrived four days late, so the sprint clock paused, as agreed at scoping
What existed at the end
First pull request merged on day seven: mailbox and portal intake landing documents in the client's storage
What happened
Extraction and matching running behind a feature flag on real invoices. Golden set agreed with AP
What existed at the end
A working prototype and a golden set of 1,200 historical invoices with known answers
What happened
Validation rules, matching engine, exception queue, ERP write-back through the import interface, audit log, dashboards. Shadow run began in week four
What existed at the end
A system making every decision in parallel with the team, without posting
What happened
Live for 10% of suppliers, then 50%, then all in scope, each step gated on the shadow-run comparison
What existed at the end
Real invoices posting, rollback one switch away
What happened
Client's platform engineer performed a release, a rollback and a tolerance change without us at the keyboard
What existed at the end
Signed runbook, decision record, revoked access
The four days were the paused clock in week one
Calendar time was six weeks and four days. The four days were the paused clock in week one. They were written down when they happened, not explained at the end.
FDE / 05Case study
05 / 12
In shortThe model reads each invoice; fixed rules check it, match it and decide whether it posts.
Try an invoice08 ops
Pick what arrives. Watch where it goes.
The same pipeline reads every document. The model only reads; fixed rules decide whether it posts or goes to a person.
Posted to the ERP
Posted to the ERP
No one keyed it. The posting is reversible in the ERP in the usual way.
Intake. Documents from the mailbox and the supplier portal land in the client's storage with a content hash. The hash catches exact duplicates at the door.
Classify. A small classifier separates invoices from statements, credit notes, delivery notes and everything else a supplier attaches. Anything out of scope goes to the existing manual queue, untouched.
Extract. A layout-aware document model reads the page. A language model, reached through a private endpoint in the client's region with no data retention, fills a strict schema: supplier, tax identifier, invoice number and date, PO number, line items, tax, totals, bank details. Each field carries the page region it came from, so a reviewer sees the evidence, not just the value.
Validate. Deterministic checks the model cannot talk its way past: tax identifier checksum, arithmetic of lines, tax and totals, date sanity, PO number format, and a near-duplicate check on supplier, number, date and amount.
Match. A rules engine, not a model, performs the three-way match against the PO and goods receipt read from the ERP replica. It applies the Controller's tolerance bands: unit price within 1%, quantity no more than received, total within a fixed amount. A missing goods receipt does not fail the match. The invoice waits and retries for up to 48 hours, which removed the largest class of false exceptions found at scoping.
Decide. Three outcomes only:
Post, when every validation passes, the match is within tolerance and the supplier's bank details are unchanged from the master record.
Exception, with a named reason and the evidence, when anything else is true. Changed bank details always land here, with a flag for a call-back to the supplier on a known number.
Reject, for duplicates and documents that fail validation outright.
Post. Write-back uses the ERP's approved import interface, as a service account with the same posting permissions an AP clerk has. Every posting is reversible in the ERP in the usual way.
Audit and monitoring. Every decision, with its inputs, rule results and model version, goes to the client's log store. Dashboards show volume, touchless rate, exception reasons and accuracy from the weekly sample audit. Thresholds page the platform engineer when the touchless rate or the audit accuracy drops.
System map19 objects
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Graph01 / 09
Description
Every supplier invoice was typed in by hand.
About 14,000 invoices a month, keyed into the ERP by nine people. An invoice took a median of 11 days to post, and early-payment discounts were lost.
FDE / 06Case study
06 / 12
In short1,200 past invoices, with answers from the ledger, scored field by field on every change.
The golden set was the most important artefact of the engagement.
1,200 historical invoices, sampled across suppliers, layouts, digital and scanned documents, both currencies and every month of the prior year.
Answers taken from the ledger: what was actually posted after AP corrections, not what the invoice appeared to say.
A red-team slice: known duplicates, invoices with altered bank details, totals that do not add up, and a PO number belonging to another supplier.
Field-level scoring, so a wrong tax amount counts as wrong even when the supplier and total are right.
- supplier
- tax identifier
- invoice number and date
- PO number
- line items
- tax
- totals
- bank details
WHOLE ORDER · ALL 8 FIELDS
TAP A FIELD
The suite runs in the client's CI. A change that drops any critical field below its threshold fails the build and cannot be released. In week three it did exactly that: a prompt change improved line-item reading and quietly broke tax extraction on one supplier's layout. The harness caught it before any person would have.
- IF drops any critical field below its thresholdBLOCKS
fails the build and cannot be released
FDE / 07Case study
07 / 12
In shortEverything runs in the client's own cloud, and risky changes always go to a person.
Perimeter. Everything runs in the client's cloud account and region. Egress is limited to the private model endpoint, and that endpoint retains nothing.
Identity. The service account can post AP documents and nothing else. Our engineer's access went through the client's identity provider, showed in their audit log like anyone else's, and was revoked at handover.
Autonomy is bounded. The model reads; rules decide. Bank-detail changes, amounts above a set value and new suppliers always go to a person. The Controller can tighten any of these in configuration without a release.
Review. The security team reviewed the design in week two and the deployment in week five. Their findings and how each was closed are in the decision record.
FDE / 08Case study
08 / 12
In shortA week side by side with the team, then live supplier by supplier, with one flag to turn it off.
The shadow run was the gate. For a week the system decided every in-scope invoice while the team processed as before, and the two were compared line by line. Disagreements were sorted into three piles: the system was wrong, the person was wrong, and the tolerance was unclear. The third pile went back to the Controller as policy decisions.
For a week
the system was wrong
the person was wrong
the tolerance was unclear
went back to the Controller as policy decisions
Rollout went by supplier, not by date: 10% of suppliers, then 50%, then all in scope. Each step needed a clean day of audit samples. Rollback was one feature flag that returned every invoice to the manual queue. It was tested in week five and never needed.
0110% of suppliers
02then 50%
03then all in scope
EACH STEP · a clean day of audit samples
FDE / 09Case study
09 / 12
In shortThe client's engineer used the runbook for real before anyone signed it.
The engagement ended on the manifest, not on the calendar.
In the handover dry run, the client's engineer added a new supplier layout, scored it against the golden set, released it, and rolled it back, with our engineer in the room but not at the keyboard. The runbook was signed after that, not before.
Key numbers09 gauges
The story in nine numbers
One number for each scene, from 11 days to post to 61% posted with no keying. Press play, or pick a number.
ClusterStopped
ChannelOP 10 Invoice pile
ClockBefore
DialOP 10
11days
ClockBefore
Face01 / 09
ReadoutOP 10
Every supplier invoice was typed in by hand.
About 14,000 invoices a month, keyed into the ERP by nine people. An invoice took a median of 11 days to post, and early-payment discounts were lost.
Signals
About 14,000 invoices a monthNine people keying by hand38% of PO invoices needed a chaseFDE / 10Case study
10 / 12
In short61% of in-scope invoices posted with no keying, and exceptions wait 0.6 days instead of 3.2.
Figures are illustrative, measured on in-scope invoices over the first 90 days after cut-over.
61% of in-scope invoices posted with no human keying. The rest reached a person with a reason and the evidence attached, not a blank form.
BEFORE0%AFTER61%Median exception wait fell from 3.2 days to 0.6. Most of the gain came from the retry on late goods receipts and from written tolerances.
99.7% field-level accuracy on the weekly sample audit of posted entries, against a 99.5% threshold.
AFTER99.7%Duplicates stopped before payment, not found in quarterly review.
No bank-detail change accepted automatically, because the design does not allow it.
The AP team was not reduced. The most experienced clerk now owns supplier escalations and tolerance policy, work that had been waiting for years.
What did not improve, and was never promised:
FIG. 10.2Non-PO invoices, credit notes and freight invoices are still manual. They were out of scope, and the scope page said so.
Photographs of handwritten delivery notes from one plant are still read poorly. They go to exceptions, and the plant has since moved to printed notes.
FDE / 11Case study
11 / 12
In shortSix lessons for anyone automating supplier invoices.
- Write the tolerances down before you build anything.
Half of the exceptions were a policy nobody had written.
- Measure on your own worst documents.
A vendor's clean sample says nothing about your scanned paper.
- Let rules decide and models read.
It is what made the security review short and the audit easy.
- Timing looks like error.
Check when your data arrives before blaming the matcher.
- Pause the clock in writing.
A late access grant is not a slip if both sides recorded it the day it happened.
- Handover is a rehearsal, not a document.
The runbook was worth signing only after the client's engineer had used it.
FDE / 12Case study
12 / 12
In shortThe client took it in-house, extended it to credit notes, and came back for supplier onboarding.
The client took the system in-house and did not buy managed operations. Two months after handover their own team extended it to credit notes, using the same harness and runbook. They came back for a second Production Sprint on supplier onboarding, which had been out of scope the first time.