One Workflow Across Two Entities Before The ERP Merges

The deal closed. The integration plan has a workstream for systems, and that workstream has a date on it that is 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, starting immediately. 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 for this period to have its own operating model, so it does not have one — 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 rather than companies, and a considerable number of them describe this exact interval.

Two Of Everything, One Deadline

The interim period is difficult for a reason that is easy to underestimate: almost nothing is shared, and the differences are not visible until a transaction hits them.

• Two charts of accounts. Not just different codes — different granularity, different revenue cut, different treatment of the same cost.
• Two approval hierarchies. Different thresholds, different roles, and an approver in one company who has no identity in the other's systems.
• Two definitions of done. One entity considers an order complete at shipment, the other at customer acceptance. Both are defensible and they produce different numbers in the same month.
• Two calendars. Different close timetables, different cut-off conventions, sometimes a different fiscal year end.
• 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 the two are one person.

Integration research has been consistent about where value is lost. 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. The review of evidence and perspectives on mergers (Andrade, Mitchell & Stafford, Journal of Economic Perspectives, 2001) documents how uneven acquirer returns are. Neither result is about software. Both are about whether the combined company can actually 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, and so it is never designed, documented, staffed or controlled. It nevertheless has every property of a production system: it runs continuously, it produces numbers that reach a filing, and it fails in ways that matter.

graph TD
    A["Entity A<br/>chart, approvals, calendar"] --> W["One workflow layer<br/>mapping · approvals · evidence"]
    B["Entity B<br/>chart, approvals, calendar"] --> W
    W --> C["Posted to Entity A ledger"]
    W --> D["Posted to Entity B ledger"]
    W --> E["One record: who, when,<br/>which mapping version"]

    style A fill:#1a1a2e,stroke:#0f3460,color:#fff
    style B fill:#1a1a2e,stroke:#0f3460,color:#fff
    style W fill:#1a1a2e,stroke:#ffd700,color:#fff
    style C fill:#1a1a2e,stroke:#0f3460,color:#fff
    style D fill:#1a1a2e,stroke:#0f3460,color:#fff
    style E fill:#1a1a2e,stroke:#16c79a,color:#fff

The risk in the interim period is rarely that the work is done wrongly. It is usually done well, by people who care. The risk is that it is done in a way nobody else can reproduce, verify or take over, which is the condition described in performed well and unprovable. This is also the interval when the auditor is paying the most attention. The conditions most associated with disclosed control weaknesses (Doyle, Ge & McVay, Journal of Accounting and Economics, 2007) include exactly this one: recent restructuring, rapid change and organizational complexity.

A Mapping Is A Deliverable, Not A Meeting

The single most useful move in this period is to stop treating the translation between the two companies as knowledge and start treating it as data.

Four things need to become explicit artifacts rather than understanding held by one team:

• The account mapping, versioned and dated, so that a number produced in March can be explained with the mapping that was in force in March rather than the one in force today.
• The approval matrix, expressed as rules over amount, entity, category and role, with a named fallback for every rule. The fallback is the part people skip and the part that stops the process when someone is travelling.
• One definition of done, written once and expressed as the set of records a completed item must carry. Where the two companies genuinely differ, the difference is recorded as a rule with a reason rather than resolved in someone's head.
• The exception list, with an owner and a state for each item, so that "waiting on the other entity" is a visible condition rather than a silence.

None of these four is a large piece of software. Together they are the interim operating model, and they are also, not coincidentally, the artifacts the consolidation project will need as input when it finally starts. A team that has already written the account mapping down as data has removed a substantial part of the migration's discovery phase.

Build So It Survives The Consolidation

The reasonable objection to building anything now is that the enterprise systems will merge and the work will be thrown away. That is avoidable, and it is a design decision rather than a matter of luck.

Three rules make the interim workflow outlive the interim period. Keep every connection to a source system behind a single adapter per system, so that when two ledgers become one, you retire an adapter rather than rewrite the process. Hold the mapping as configuration rather than as code, so that 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 that 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. The process itself, the approvals, the exception handling and the record all continue running. 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.

The alternative is worse than it looks. If the interim process stays manual until consolidation, then on the day the systems merge you still do not have a designed process — you have the same spreadsheet pointed at one ledger instead of two, and a control finding that survived the project that was supposed to fix it.

First Steps

1. Ask who could run the cross-entity process next week if the person who owns it were unavailable. If the answer is a name plus a caveat, the mapping is not documented; it is remembered.
2. Get the account mapping out of the spreadsheet and into a versioned file with a date and an owner. This costs an afternoon and it is the input the consolidation project will ask for anyway.
3. List the last twenty exceptions and how each was resolved. Patterns in that list are rules. Rules can be built. What is left over is the genuine judgement, and that is the part that 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 simply not a plan for this quarter, and the exposure that 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 combined process must produce, and what it takes to build. It also says plainly when the answer is 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 monthly — full history and documentation. Afterwards, $15,000 a month keeps one accountable person on it through the period when both source systems are still changing underneath — which, during an integration, they will be. The systems merge when they merge. The process runs on Tuesday.

References

1. Larsson, R., & Finkelstein, S. Integrating Strategic, Organizational, and Human Resource Perspectives on Mergers and Acquisitions: A Case Survey of Synergy Realization. Organization Science, 1999.
2. Andrade, G., Mitchell, M., & Stafford, E. New Evidence and Perspectives on Mergers. Journal of Economic Perspectives, 2001.
3. Doyle, J., Ge, W., & McVay, S. Determinants of Weaknesses in Internal Control over Financial Reporting. Journal of Accounting and Economics, 2007.
4. U.S. Securities and Exchange Commission. EDGAR Full-Text Search. Filing counts cited are from full-text search over the trailing twelve months.