Case studies
The power of NAP, in production, against real clients.
Real deployments in live finance operations. Client size, region, vertical and systems are stated on every one, along with what broke, what changed, and by how much.
Case 01 · Migration
A building products group moved six subsidiaries onto one ERP after the first attempt reversed at cutover.
Vertical
Construction and building products
Client size
$300-500M revenue · 6 subsidiaries
Region
North America
Systems
Microsoft GP → Microsoft BC
Engagement
10 Days
Situation
A group operating six subsidiaries had grown through acquisition, and each company arrived with its own chart of accounts, its own approval matrix, and its own treatment of intercompany transfers. Finance was consolidating in spreadsheets and closing on a three-week lag.
The migration had been attempted once already. It reversed at cutover, because the environment did not match what discovery had described.
THE SAME CUTOVER, BOTH WAYS
FIRST ATTEMPT
Entity rules surfaced during migration
Reconciliation done by hand afterwards
Cutover reversed
WITH NAP
Environment read and modelled first
Field map approved before anything moved
Cutover declared against a balance
Approach
NAP read the environment rather than describing it. Six entities, thirty-seven custom fields of which eleven were undocumented, four distinct approval paths, and two endpoints that were not safe to retry.
The field map was produced and approved before anything moved. Open balances, history, and master data then migrated under a $0.00 gate enforced at the database layer rather than in application logic that can be bypassed.
Cutover was not declared against a checklist. It was declared against a balance.
$0.00
Variance per entity before the group close is permitted
32
Entities migrated and gated in a single engagement
2,200+
Encoded patterns applied before the first field moves
10 days
Kickoff to production on a multi-entity migration
Case 02 · Production support
A logistics operator took its accounts payable exception queue from a shared inbox to one person on exception.
Vertical
Transportation and logistics
Client size
Multi-entity · 256K transactions/day
Region
North America
Systems
ERP · procurement · banking
Engagement
Ongoing
Situation
Accounts payable was running at a volume where manual review had stopped being viable but had not stopped being the process. Exceptions landed in a shared inbox and a team worked through them each morning.
The reviewers were not slow. Every exception arrived as a symptom rather than a cause, and the analysis was thrown away the moment the ticket closed.
WHAT REACHES A PERSON
BEFORE
Every exception lands in a shared inbox
Symptom reported, cause unknown
Same failures diagnosed each cycle
WITH NAP
Root cause named with payload and step
Resolved once, then encoded
Two or three items reach a person overnight
Approach
NAP's production support agent names the root cause with the payload, the step, and the system that returned it. A duplicate vendor payment, for instance, is usually reported as a duplicate invoice. Here it was a retry against an endpoint that was not idempotent.
Once that distinction is drawn the resolution is permanent. The second post reverses, an idempotency key is applied, and the pattern is written into the Forensic Library, where it applies to every matching transaction afterwards.
An exception gets resolved once. What happens afterwards is that it stops being an exception.
256K
transactions per day
1
human in the loop
0
recurrence after encoding
Flat
headcount as volume grew
Case 03 · Connectors and migration
Thirty-two entities across a homegrown ERP and Microsoft Dynamics GP, connected and consolidated onto one ledger.
Vertical
Multi-entity operating group
Client size
32 legal entities
Region
North America
Systems
Homegrown ERP · Microsoft Dynamics GP
Engagement
Connector build and migration
Situation
The group ran two finance systems side by side. One was written internally more than a decade earlier, held the commercial logic for a large part of the book, and had no documentation and no vendor. The other was Microsoft Dynamics GP, on premise, with a separate company database for each of thirty-two legal entities.
Nothing connected them. Consolidation happened in spreadsheets, entity by entity, every month. Both systems had to be understood before either could be connected, and no vendor had been willing to take on the homegrown side.
Approach
NAP took the homegrown system first, because it was the constraint. The Discovery Agent read the schema directly rather than working from an interview, and returned the object model, the custom fields nobody had documented, and the endpoints that were not safe to retry. One of those would have produced a duplicate payment in production. It was flagged and guarded before the build began.
Dynamics GP came second. Thirty-two company databases meant thirty-two variations of the same entity logic: different approval matrices, different intercompany treatment, and vendor records duplicated across companies with divergent terms. The Mapping Agent resolved each company scope separately rather than assuming a shared schema.
Only then was the connector built, bidirectional across both systems. Data for all thirty-two entities was migrated under the Guard, with the trial-balance gate enforced per entity rather than at the group level. No entity cleared until its own variance reached zero, and consolidation was not permitted until all thirty-two had.
Phase 01
The homegrown ERP
Read the schema directly No documentation existed documented fields mapped
Phase 02
Dynamics GP
32 company databases Entity rules differed per companyIntercompany sequencing resolved
Phase 03
The connector
Bidirectional, both systems Retry-unsafe endpoint guarded1,407 checks before go-live
Phase 04
The homegrown ERP
32 entities moved $0.00 gate enforced per entityCutover declared against balance
Thirty-two entities meant thirty-two gates. The group close waited for the last one.
32
entities migrated and gated
2
source systems, one connector
1,407
checks before go-live
$0.00
variance per entity