One Workflow Across Two Entities Before The ERP Merges
Apr 3, 2026Omar Trejo5 min read
The deal closed. The integration plan has a systems workstream, dated somewhere between nine and twenty-four months away. Everything about that plan is reasonable.
Meanwhile a process has to run every week across both companies. Orders taken by one entity are fulfilled by the other. A customer who now belongs to both receives two invoices with different terms. A purchase approved under one authority matrix is paid out of an account that lives under the other. Nobody planned an operating model for this period, so it has a person who understands both sides and a spreadsheet that maps between them.
That person is now a single point of failure for a public company's reporting, and the mapping in their file is the only place two charts of accounts have ever been reconciled. Over the trailing twelve months, SEC full-text search returns 85 filings mentioning the integration of an acquired business and 36 filings announcing a new chief operating officer. Those are filings, not companies, and many of them describe this exact interval.
One process spanning two approval chains.
Two Of Everything, One Deadline
Almost nothing is shared, and the differences are not visible until a transaction hits them.
Two charts of accounts. Different granularity, revenue cut, and cost treatment.
Two approval hierarchies. Different thresholds, different roles, and an approver in one company who has no identity inside the other company's systems.
Two definitions of done. One entity counts an order done at shipment, the other at customer acceptance. Both are defensible, with different numbers in one month.
Two sets of identities. The directory merge is its own project, so the same person may act under two accounts, and neither system can prove they are one person.
The case survey of synergy realization in mergers and acquisitions (Larsson & Finkelstein, Organization Science, 1999) found realized synergy driven by the degree of actual organizational integration rather than by strategic fit on paper. That is about whether the combined company can execute a process end to end, which in this interval it does by hand.
The consolidation project has a date. The process has a Tuesday.
The Interim Process Is A Real System
The temporary arrangement is treated as temporary, so it is never designed, documented, staffed or controlled. It still has every trait of a production system: it runs continuously, it produces numbers that reach a filing, and it fails in ways that matter.
The interim risk is rarely that the work is done wrongly. It is that nobody else can reproduce, verify or take it over, the condition described in performed well and unprovable. The auditor pays the most attention in this interval. The conditions most associated with disclosed control weaknesses (Doyle, Ge & McVay, Journal of Accounting and Economics, 2007) include this one: recent restructuring, rapid change and organizational complexity.
The interim process needs an owner too.
A Mapping Is A Deliverable, Not A Meeting
The single most useful move in this period is to treat the translation between the two companies as data, not knowledge. Four things become explicit artifacts:
The account mapping, versioned and dated, so a number produced in March can be explained with the mapping that was in force in March rather than today's.
The approval matrix, expressed as rules over amount, entity, category and role, with a named fallback for every one of the rules. The fallback is the part that people skip, and it is the part that stops the process when somebody is travelling.
One definition of done, written once and expressed as the records a completed item must carry, with genuine differences recorded as rules with reasons.
The exception list, with an owner and a state for each of the items, so that "waiting on the other entity" is a condition that is visible rather than a silence.
None of these is a large piece of software. Together they are the interim operating model, and also the artifacts the consolidation project will need as input when it starts.
Build So It Survives The Consolidation
The reasonable objection is that the systems will merge and the work will be thrown away. That is avoidable by design. Three rules make the interim workflow outlive the interim. Keep every connection to a source system behind one adapter per system, so when two ledgers become one, you retire an adapter rather than rewrite the process. Hold the mapping as configuration rather than code, so changing it is an operational act with a version and a date rather than a release. Store the evidence — who did what, when, under which mapping version — independently of both ledgers, so neither migration takes the audit trail with it.
Do that, and the day the consolidation lands is a day you delete one adapter and simplify one mapping table. This is the same principle as building around the enterprise system rather than instead of it, applied to a period where there are two of them.
First Steps
Ask who could run the cross-entity process next week if its owner were away. If the answer is a name plus a caveat, the mapping is not documented; it is remembered.
Get the account mapping out of the spreadsheet and into a versioned file with a date and owner. It costs an afternoon, and the consolidation project will ask for it anyway.
List the last twenty exceptions and how each was resolved. Patterns in that list are rules. Rules can be built. What remains is judgement, which should stay with a person.
The Quarter You Have, Not The Year You Are Promised
The consolidation project is not the wrong plan. It is not a plan for this quarter, and the exposure the audit committee will ask about is a this-quarter exposure.
A fifteen-minute call, nothing paid, nothing signed, takes one cross-entity process apart: what the mapping has to hold, where the approval rules split, which records the process must produce, and what it takes to build. It also says plainly when to wait: if consolidation is four months out and the process runs twice a quarter, waiting may be correct.
Where it is not correct, that work runs as a monthly engineering partnership: one prioritized delivery lane, targets agreed before each release, and paid-for deliverables transferring to you each month, with full history and documentation. Afterwards, $10,000 a month keeps one accountable person on the process while both source systems are still changing underneath it. The systems will merge when they merge. The process has to run on Tuesday.
