How do you unify order-to-cash after an acquisition?

Key Takeaways

Unified order-to-cash after an acquisition is one rulebook, one customer view, one worklist and one set of KPI definitions; each company’s ERP keeps its own books.
Days 0-30 keep invoicing and cash running and build one view of shared customers; days 31-60 prove the rulebook on one entity; days 61-90 extend and measure.
Deloitte warns that during a deal “one misstep may mean thousands of invoices go unpaid for months”, so continuity comes before any change.
KPMG Germany’s 2024 post-merger guide for financial-services firms puts the IT platform decision within the first 100 days and expects synergies usually within 12 to 24 months.
Transformance connects to an entity’s ERP in typically 2-3 days (your IT team may be involved), and nothing posts without human sign-off.

Key Takeaways
How do you unify order-to-cash after an acquisition without replacing ERPs?
What happens in days 0 to 30?
What happens in days 31 to 60?
What happens in days 61 to 90?
Which order-to-cash steps should you unify first?
What stays in each ERP, and what does the group own?
How does Transformance fit into the 90 days?
Which KPIs show that the unified process works?
When should you decide whether to move to one ERP?

How do you unify order-to-cash after an acquisition without replacing ERPs?

Keep both ERPs as the books and run one 90-day plan above them: continuity and a customer view first, one rulebook proven on one entity next, then extension and KPIs.

A 90-day plan for order-to-cash after an acquisition, with both ERPs kept

Window	Goal	What people do	What the ERPs keep doing	Shared AR layer	Exit gate	Owner
Days 0-7	Keep cash and invoicing running	List entities, ERPs, banks and payment channels; name one O2C owner per side; freeze master-data and bank changes	Invoice, receive, apply, dun and close as before	Not yet	Both sides invoice and apply cash on schedule	Finance leads of both sides
Days 8-30	See everything once	Aging snapshot per ERP at one date; cross-reference for shared payers; baseline five KPIs; draft rulebook	Unchanged; pre-closing open items stay in the acquired ERP	Not yet: the work is manual and owned by people	One aging per shared customer; signed baseline; draft rulebook; pilot entity named	O2C owner and master data team
Days 31-60	Prove one rulebook on one entity	Connect the pilot entity’s ERP; approve proposals within thresholds; map reason codes; send payment-instruction notices	Entity keeps ledger, open items, postings and period close	Reads bank and remittance data; Vero proposes with evidence; nothing posts without sign-off	Pilot KPIs vs baseline; thresholds signed by the controller	SSC lead; entity controller approves
Days 61-90	Extend, measure, then decide	Add the next entity or ERP; one AR collections worklist; one KPI pack; write the ERP decision input	Unchanged	One worklist, one set of categories, one KPI definition set	Rulebook v1 signed; group KPI pack issued; decision input documented	Group AR owner; CFO decides the ERP roadmap

This plan is our guidance, not a benchmark. ERP terms are the ERP vendors’ own. The “Shared AR layer” column is a role in your plan; Transformance’s part is described further down.

‍

Four windows, 90 days

1Days 0-7: Keep running

2Days 8-30: One view

3Days 31-60: Prove rulebook

4Days 61-90: Extend, measure

‍

Unified order-to-cash is one policy, one customer view, one worklist and one set of KPI definitions across both companies, not one ERP and not one database. The object-by-object split is in one AR process across SAP, Oracle and NetSuite.

Continuity comes first. Deloitte’s Day One readiness guide says invoices still have to be sent and payments collected, and that “one misstep may mean thousands of invoices go unpaid for months, severely impacting cash flow” (Deloitte).

In post-merger integration, KPMG Germany’s guide for financial-services firms places the decision on which IT platform to use within the first 100 days and says leaders want synergies visible, usually within 12 to 24 months (KPMG Germany, 2024).

‍

What happens in days 0 to 30?

Keep invoicing, cash application and dunning running in each ERP unchanged, then build one list of shared customers, one aging snapshot and one draft rulebook.

Days 0 to 7: continuity.

List every entity with its ERP, bank accounts and payment channels, in each ERP’s terms: SAP company code, Oracle Fusion business unit and ledger, NetSuite subsidiary, Dynamics 365 legal entity.
Name one order-to-cash owner per side.
Freeze changes to payment terms, bank details and customer masters, except what the deal requires.
Confirm both close calendars, and keep the acquired side’s invoice layout and remit-to details until customers have been told otherwise.

Days 8 to 30: see everything once.

Take an aging snapshot in each ERP at one cut-off date: open items, not balances, so a credit memo shows as its own line.
Build a customer cross-reference for the shared payers with the most open value. Illustrative example: a customer is 100245 in SAP company code 1710 on net 30 and CUST-0388 in the NetSuite subsidiary on net 45, with USD 412,000 open across both. The row holds both numbers, both terms, payer versus bill-to and one owner.
List the payments that still arrive on the acquired company’s old bank account, and keep reading its statements until customers have switched.
Baseline five KPIs on one definition (see KPIs below).

Draft the group rulebook as a checklist: reason codes, short-pay tolerances, dunning stages, dispute categories and approval thresholds by amount, entity and customer. Mark what stays local: contract payment terms, legal wording, banks and close calendars.

Ask the ERP teams now for a technical contact, read access and a test period.

Exit gate (our guidance): one consolidated aging per shared customer, a signed KPI baseline, a draft rulebook and a named pilot entity.

What happens in days 31 to 60?

Prove the rulebook on one entity: connect its ERP, let Vero propose matches and exceptions with evidence, and have a person approve each proposal within thresholds.

Pick the pilot on volume and data quality. With Transformance, an ERP connection typically takes 2-3 days, and your IT team may be involved. A proof of value runs 4-5 weeks on one entity; if it needs its fifth week, move the day-60 gate with it.

Start with cash application, where the two companies’ numbers are hardest to compare: open item, payment, remittance and clearing differ per ERP. Nothing posts without human sign-off; admins configure rules, finance approves within thresholds. See who approves what when an AI agent works in your ERP.

Map the pilot’s reason codes and tolerances to the group list; a short pay coded “pricing” on one side and “other” on the other hides the pattern.

Tell customers what changes: send the payment-instruction notice for changed bank details or entity, in your company’s own wording. Then watch for payments to the wrong entity: see how cash application handles intercompany and multi-currency payments.

Expect these failure modes:

Locked posting periods. The acquired entity closes on working day 3; a September clearing approved on working day 4 needs an open period or the controller’s call (illustrative).
Blocked documents. An item with a dunning block or dispute flag waits for its owner.
Pre-closing open items stay in the acquired ERP and are collected there.
Residual items and currency differences. A USD 1,240 short pay sits as a residual item under the old reason code (illustrative); a EUR invoice paid in USD leaves an exchange difference one entity has to book.

Exit gate (our guidance): pilot KPIs against the day-30 baseline, thresholds signed by the entity controller, a list of exceptions that needed a rule change.

What happens in days 61 to 90?

Extend to the next entity or ERP, run one AR collections worklist, publish one KPI pack on one definition, and write down what the data says about the ERP roadmap.

Extend. A second entity on the same ERP uses the same connection method. An entity on a different ERP needs its own connection, typically 2-3 days, and your IT team may be involved. Per ERP, multiple SAP instances and company codes, NetSuite subsidiaries or Dynamics 365 legal entities consolidate in one Transformance environment. Oracle is supported.

One AR collections worklist. Cadence by segment, promises to pay, disputes and deductions sit in one case list with one set of categories, owned by the central AR collections team, so a shared customer gets dunned from one place, not from two. Multi-currency dunning is covered in running AR across many legal entities.

One KPI pack: five KPIs, one definition each, per entity and group, monthly from day 90.

Write the decision log: effort per ERP, data quality per entity, master-data exceptions and what running two ERPs costs you.

Exit gate (our guidance): rulebook v1 signed by the group owner and entity controllers, group KPI pack issued, ERP decision input documented.

Which order-to-cash steps should you unify first?

Unify what you can see and measure first: customer view and open items, then cash application, then AR collections and disputes; leave order entry, pricing and billing in each ERP.

Customer view and aging: the cross-reference and one consolidated aging per shared customer.
Cash application: one matching rulebook, one reason-code list, approvals by threshold.
AR collections cadence: one worklist, one segment logic, one promise-to-pay record.
Deductions and disputes: one set of categories and one owner per category.
Cash forecast: once open items and payment behaviour are visible in one way.

Order entry, customer terms and billing stay in each ERP. See the enterprise ERP order-to-cash playbook.

What stays in each ERP, and what does the group own?

Each ERP keeps its entity’s ledger, customer accounts, open items, postings and period close; the group owns the rulebook, the customer cross-reference and the KPI definitions.

In SAP, the company code is “the smallest organizational unit of external accounting for which a complete, self-contained set of G/L accounts can be created”, usually one legal entity (SAP Learning, accessed 2026). In NetSuite OneWorld, the Multi-Subsidiary Customer feature shares one customer record with several subsidiaries (NetSuite help, 2026). In Oracle Fusion Receivables, customer sites and customer account relationships sit in business-unit-specific reference data sets (Oracle Help Center, 2025).

So the acquired entity’s books, clearing, write-offs and period close stay where they are. The customer cross-reference belongs to your master data team or shared service centre; each ERP keeps its own customer record. The object-by-object table is in the one AR process guide.

How does Transformance fit into the 90 days?

Transformance connects to the entity’s ERP in typically 2-3 days from day 31, proposes matches with evidence from Customer 360, and posts only after a person approves.

ERPs. Transformance connects to SAP S/4HANA and SAP ECC, NetSuite including OneWorld, Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo, all in production with customers. Oracle and Infor are supported. See which ERP systems Transformance integrates with.

Connection. The method follows your environment and is agreed with your IT team: APIs, RFC/BAPI and IDoc for SAP, file or SFTP, middleware, SAP Cloud Connector, a customer Azure app registration, or Transformance’s own on-premises agent. No custom ABAP, no modification in your SAP system.

Reads and writes. Transformance reads customer master data, open items, invoices, bank statements and remittances. DocSense reads remittances with over 97% extraction accuracy across 100+ document types and 170+ languages, with no templates. Clearing postings, journal entries and ERP updates, including reversals, go to the entity’s own ERP after approval. The field map is in what AR automation reads from and writes to the ERP.

Vero. For an unmatched or partly matched payment, Vero investigates from Customer 360, fetches internal and external information to find more matches, and proposes with the evidence attached. A person approves, and postings follow the thresholds by amount, entity and customer within a multi-level approval model (read, recommend, execute, post).

Controls. ClearMatch validates 100% of postings, and nothing posts without human sign-off. The audit log stores six things for every action: the timestamp, what the system did, what the user did, who approved, the input and the confidence (audit trail guide).

Timing. In your plan, the connection and the proof of value on one entity sit in days 31 to 60; the proof of value runs 4-5 weeks. The full rollout is a separate figure, up to 4-8 weeks; see how long AR automation implementation takes.

Which KPIs show that the unified process works?

Track five KPIs on one definition across both companies: DSO, unapplied cash age, overdue share, dispute cycle time and items needing a person; compare them against the day-30 baseline.

DSO is the average number of days to collect receivables, calculated with one method in both companies. Countback on one side and a 90-day average on the other blends two measures (days sales outstanding).
Unapplied cash age is how long received cash waits before it is applied, including on-account cash.
Overdue share is overdue open items as a share of all open items, by value, at the same cut-off date each month.
Dispute cycle time is the days from opening a dispute case to resolving it.
Items needing a person is the share of payments and cases needing manual work beyond an approval.

Report per entity and for the group against the day-30 snapshot, not a pre-deal period. This plan sets no targets. One DSO method across entities is covered in enterprise dunning across entities.

When should you decide whether to move to one ERP?

Decide at the end of the 90 days, on data: the unified process does not depend on one ERP, so the migration case rests on cost, risk and roadmap.

That still fits the 100-day window KPMG Germany sets for the IT platform decision (2024), now with evidence: 90 days of KPIs per entity, effort per ERP and the master-data issues the pilot surfaced.

Some groups consolidate onto one ERP; others keep acquired units on a second ERP, often called two-tier ERP. This plan supports both.

If an ERP is replaced later, the rulebook, cross-reference, KPI definitions and approval thresholds carry over; the connection and the code mappings move to the new ERP. For SAP, see automate AR before or after the S/4HANA migration and the SAP ECC integration.

Who Transformance is for

ERPs: groups that now run two or more ERPs after an acquisition, with SAP S/4HANA or SAP ECC, NetSuite (including OneWorld subsidiaries), Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo in production with customers; Oracle and Infor supported.
Size: mid-market to large enterprise, 250 to 2,000+ employees, including groups with several entities and shared service centres.
Payment volume: from under 1,000 to over 100,000 payments a month.
Industries: manufacturing, consumer goods and food and beverage, logistics, e-commerce, agriculture, energy and professional services.
Scope: cash application alone, or the full order-to-cash (cash application, deductions, AR collections, cash forecasting).

Conclusion: run the plan, then decide the ERP

After an acquisition, order-to-cash needs one plan, not one ERP. Keep cash running, see every shared customer once, prove one rulebook on one entity, then extend and measure. The ERP question comes last, with 90 days of data behind it.

Transformance works with customers such as Syngenta, Eberspächer and PwC, across Europe, the United States and Australasia.

Key terms

Order-to-cash: the process from customer order to cash received and applied, here across two companies.
Master data management: keeping customer records consistent; here, the cross-reference of one customer’s numbers in each ERP.
Sub-ledger: the customer ledger in each ERP, where open items stay per entity.
Cash application: matching a payment to the open items it pays; the usual first process to unify.
Days sales outstanding: the average number of days to collect, calculated one way in both companies.

Related guides

‍

Frequently Asked Questions

Do we have to replace the acquired company’s ERP to unify order-to-cash?

No. One order-to-cash process needs one rulebook, one customer view and one set of KPIs, while each company’s ERP stays the system of record for its books.

Which ERPs does Transformance connect to after an acquisition?

Transformance connects to SAP S/4HANA, SAP ECC, NetSuite including OneWorld, Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo, all in production with customers, and supports Oracle and Infor.

Can Transformance handle several entities and instances after a deal?

Yes. Per ERP, multiple SAP instances and company codes, NetSuite subsidiaries or Dynamics 365 legal entities consolidate in one Transformance environment. Oracle is supported.

How long does it take to connect and roll out?

An ERP connection typically takes 2-3 days, and your IT team may be involved. A proof of value runs 4-5 weeks on one entity, and the full rollout takes up to 4-8 weeks.

What payment volume is Transformance built for?

Transformance works for payment volumes from under 1,000 to over 100,000 payments a month, including groups with several entities.

What do we do about customers that exist in both ERPs?

Each ERP keeps its own customer record, and your master data team owns the cross-reference that links the customer’s numbers in each ERP. Build it for the shared payers with the most open value within 30 days of the deal.

What does it cost to unify order-to-cash after an acquisition with Transformance?

The cost depends on scope and the number of entities, from cash application alone to the full order-to-cash. Book a Call and we size it with you.

SAP, SAP S/4HANA, Microsoft, Dynamics 365, Business Central, Oracle, NetSuite, Odoo and Infor are trademarks of their respective owners (SAP SE, Microsoft Corporation, Oracle Corporation, Odoo S.A., Infor). Transformance is not affiliated with or endorsed by them.