Post-M&A Integration Checklist for the CFO Who Has to Run the Combined Finance Function

The post-M&A integration checklists that show up first on Google were written for corporate development, and a CFO inheriting the combined finance function the day after close is reading the wrong document. Corp dev’s checklist closes the deal. The finance leader’s checklist starts when corp dev’s ends, runs on a different clock, and is graded by entirely different work: cash that does not bounce, payroll that does not miss, vendors that do not get paid twice, and a first combined month-end close that ties out cleanly.

This article is that second checklist. It is sequenced by the three horizons a finance leader actually has to manage, and it is honest about the items that consistently fall through the cracks even when there is a checklist nominally in place.

What a post-M&A integration checklist actually has to cover

Three different documents get called a “post-M&A integration checklist,” and they are not the same:

• The corp dev integration plan. Workstreams across HR, IT, legal, finance, ops, and sales. Owned by an integration management office or a deal lead. Ends roughly when the combined org is operational.
• The IT systems migration plan. Identity, network, endpoint, data, applications. Owned by IT.
• The CFO’s finance integration checklist. Cash, AP, AR, payroll, chart of accounts, approvals, system consolidation, combined close. Owned by the head of finance. Narrower than the corp dev plan, deeper in finance specifics, sequenced by finance milestones rather than deal milestones.

The rest of this article is the third one.

The bar for every item on it is the same: a named owner, a due date, and a definition of done. Without all three, items slip. The finance practitioners we talk to describe this consistently. Ryan Bateman of Platform Accounting Group, in a conversation about diligence and integration, put it plainly: there are things that should happen during the diligence process that just plain do not, they fall through the cracks. The checklist is the easy part. The enforcement around it is where every CFO has been burned at least once.

Three time horizons map to the work:

• Day one (the day the deal closes): cash, payroll, signatories, vendor payment authority.
• First 30 days: chart of accounts, AP, AR, vendor and customer master consolidation, exception process for mismatches.
• First 90 days: ERP path decision, approval workflows for the combined org, tool stack consolidation, planning the first combined month-end close.

Anything that drifts past its horizon gets harder to fix, not easier, because by then the next horizon’s work has already started.

Day one finance checklist

The point of day one is continuity. Cash moves. Payroll runs. Nobody gets locked out of an account they need, and nobody pays the same vendor twice during the handoff.

• Bank account access and signatory updates. Confirm every operating account, payroll account, and merchant account for both entities. Authorized signers, online banking permissions, wire approval lists, and ACH origination rights. Update where ownership has legally transferred. Document where it has not, with the date it will.
• Approver lists across both entities. Who can authorize a wire, sign a check, release a payment file. The acquired company’s approvers stay live until the combined approval matrix is published; assume nothing about delegated authority transferring automatically.
• Payroll continuity for the acquired company’s next pay cycle. Pay date, payroll provider, tax registrations in every jurisdiction the acquired entity operates in. New jurisdictions trigger new state registrations that take real time to obtain; finance owns confirming they are in flight, not assuming HR has it handled.
• Vendor payment authority during the handoff. This is the duplicate-pay window. Both entities have AP queues. Both may have unpaid invoices for vendors that serve both companies. The risk is that the acquired entity pays an invoice the parent has already paid, or vice versa, because the vendor masters have not been reconciled yet. Practitioners describe this risk in exactly those terms: it would be very easy to double pay if both we and the other party made a payment on the same vendor. Freeze ambiguous payments to shared vendors until the master is consolidated, or route them through a single approver who can see both queues.
• Open POs, unpaid invoices, and customer credits in both systems. Inventory every one before any data migration starts. Open POs are commitments; missing them affects accruals at month-end. Customer credits left on the acquired company’s books are real liabilities and easy to forget.
• A single source of truth for cash position. Day one cash visibility across both entities. A shared spreadsheet that reconciles to bank balances is acceptable for week one. What is not acceptable is two cash views and no one whose explicit job is to reconcile them.

If even one of those items is undefined at close, the day-one checklist is not done. There is no version of “we will get to that next week” that ends well.

First 30 days: AP, AR, and the reconciliation work nobody scoped

The first 30 days are where the work corp dev did not scope shows up. Most of it is reconciliation. The two finance stacks, including charts of accounts, vendor masters, customer masters, sales tax setups, and bill payment systems, have to be made to agree before consolidation is even possible.

• Side-by-side chart of accounts mapping. Pull both COAs into a single sheet. Decide which structure the consolidated business will adopt. Map every account on the deprecated COA to its new home. This is the work that drives most of the next 30 days; pretending it is straightforward is the most common 30-day mistake.
• Vendor master consolidation. Pull vendor lists from both AP systems. The same legal entity will appear under different display names, different addresses, and different remit-to instructions. Build a consolidated master with one record per legal vendor. Flag the duplicates and decide which record survives.
• Customer and distributor billing arrangements. Both entities may have separately invoiced or been paid by the same counterparty. Reconcile open AR balances against the counterparty’s own AP records where you can get them. Resolve before the first combined statement goes out.
• An exception process for invoices and payments that do not match. During the transition window, invoices will arrive that do not match a PO in the system you expect, or that match an old vendor master record. Set up an explicit exception path. A human reviewer looks at the mismatch, decides whether to clear it manually, push it back to the vendor, or route it for approval. Auto-clearing is the wrong default during a transition; the cost of clearing a bad match is higher than the cost of pausing.
• Document the manual reconciliation steps you are doing. Every workaround your team is running during the transition is a workflow that will need to be either eliminated or automated in the 90-day horizon. If you do not write it down while you are running it, you will rebuild it from memory in three months and the documentation will be wrong.

The first month-end close as separate entities, with the parent consolidating the acquired numbers through journal entries, is where the 30-day work gets tested. If JE volume is exploding and reconciliations are not tying, the cause is the COA mapping or the vendor master before it is the systems.

First 90 days: system consolidation and approval workflow decisions

By day 90, the finance leader has enough operating data from the combined entity to make the structural decisions that day one was too early for.

• The ERP path. Three realistic options: keep both ERPs and consolidate at the GL through reporting, migrate the smaller entity onto the parent’s ERP, or run parallel through year-end close and migrate after. Year-end parallel is a common choice because it avoids forcing a mid-year migration on top of a brand-new combined close. None of the three is the right answer in the abstract; the right answer depends on transaction volume, complexity overlap, ERP versions, and how much in-flight upgrade work either entity already has.
• Approval workflows for the combined org chart. Approval limits, segregation of duties, and spend thresholds were defined for two different companies with two different risk appetites. The combined version is not the union of both. It is rebuilt for the new structure, with explicit ownership of who can approve what, against which budget, in which entity, with which delegate when they are out. Get it written, signed, and configured in the systems within 90 days.
• Tool stack consolidation across both finance functions. AP automation, expense, close software, BI, payroll, treasury, tax. Inventory both stacks. Decide which contracts to consolidate, which to terminate, and what the renewal timing looks like. Vendor seat audits where both entities have overlapping licenses are routine post-M&A money left on the table; do them in the 90-day window, not after first renewal.
• Cross-system reconciliations where consolidation is not immediate. If both ERPs are staying for a year, the gap is filled by a reconciliation cadence. Revenue, AP, and cash positions need to agree between systems on a defined frequency. This is the pattern shown in the Stripe to QuickBooks to Slack workflow: match what can be matched, flag exceptions, route mismatches to a human reviewer with context attached.
• The first combined month-end close planned as a project. The first close where both entities are on the consolidated COA, with consolidated vendor masters and consolidated approvals, deserves its own checklist, its own dry run a week ahead, and its own post-mortem after. Treating it as a routine close is the most expensive optimism in the entire 90-day plan.

A finance team that hits 90 days with a clear ERP path, a published approval matrix, a consolidated tool stack plan, and a successful first combined close has done the work. The rest of the year is normal operating, with a few cleanup tasks.

What consistently falls through the cracks

These are the items the corp dev checklist tends not to surface, that the IT plan does not own, and that finance ends up holding by default. Worth a dedicated section in your own checklist:

• Sales tax nexus changes. The acquired entity’s physical presence, customer footprint, and remote workforce can trigger nexus in states the parent never registered in. The penalty for missing this is real, and the lookback windows are long.
• Software seat audits. Both entities licensing the same SaaS vendors at separate contracts. Consolidate before renewal; vendors will not proactively offer the discount.
• Intercompany transactions starting at close. From day one, there are now intercompany payables, receivables, and transfers between the two legal entities. They need a documented process, a defined elimination treatment, and someone owning the reconciliation before the first month-end.
• Insurance, benefits, and 401(k) plan consolidation. Open enrollment timing, plan year alignment, and Form 5500 implications for retirement plans. Easily pushed to HR, but the deadlines and the dollar consequences fall on finance.
• Customer contracts with change-of-control clauses. Some require notification within a window, some require formal consent. Missing one can void the agreement or create a renegotiation opening the customer will not waste.
• Bank covenants and lender notifications. Many credit agreements require notification of material changes in ownership or structure. Check the documents the week before close, not the week after.
• Audit firm transitions. The acquired entity may have a different audit firm, a different audit year-end, or unfinished prior-year work. Decide who audits the combined entity, when, and against which opening balance sheet, before audit planning season makes the decision for you.

Most of these belong to no one on the corp dev plan because they are post-close finance work. They belong to no one on the IT plan because they are not systems. They belong to finance, and unless they are on the finance checklist with an owner and a date, they slip.

Making the checklist actually run

Here is what most post-M&A integration articles will not say: the checklist itself is not the safeguard. A spreadsheet with 137 rows and a header that says “PMI integration tracker” has never prevented a missed sales tax registration. The safeguard is enforcement: due dates that fire reminders, ownership that does not silently transfer, exceptions that route to a human, and an audit trail when something gets skipped on purpose.

This is the gap every CFO has felt during diligence and again during integration. The tracker exists. The tracker is updated when someone remembers. Items get marked done that were not actually done. Emails about blocked items get buried in inboxes. By the time the gap shows up, it is in the form of a duplicate payment, a missed registration deadline, or a covenant breach, and the audit trail for how it happened is gone.

Static checklists fail in four specific ways:

• No enforcement of due dates. Nothing chases the owner when an item is overdue.
• No visibility into what is blocked. Items sit at “in progress” indefinitely.
• No audit trail when an item gets skipped or marked done prematurely.
• No connection to the systems doing the work. An item marked complete in the tracker does not mean the state change actually happened in the ERP, the AP system, or the bank portal.

The fix is to treat checklist items as workflows, not rows. Each item has an explicit handoff, an explicit approver, a due date that escalates if it is missed, and an audit log of every state change. The items that need human judgment (chart of accounts mapping decisions, ambiguous vendor reconciliation, exception clearing) pause and ask a finance reviewer rather than auto-resolving. The items that connect to systems (vendor master updates, approval matrix changes, bank signatory updates) write through to those systems so the tracker reflects reality instead of intent.

This is exactly the seam where checklist software ends and operational reality begins. The checklist tool tracks state; the underlying systems hold the actual record; nothing natively coordinates between them, escalates a missed handoff, or routes an exception with the right context attached.

That coordination problem is what an orchestration layer is for. It sits above the systems of record, listens for what they emit, enforces due dates, pings the right human when judgment is needed, attaches full context to the ask, and keeps the audit trail intact across every handoff. FlowRunner is built for that layer. The same pattern that handles a Stripe to QuickBooks reconciliation with exceptions routed to a human handles a post-M&A integration item with a deadline, an owner, an approval gate, and an audit log. The work shape is identical; only the labels change.

A working blueprint for the finance integration checklist

Pulling the horizons and the enforcement together into something you can adapt:

• Day one items, each with a named owner and a confirm-by-close timestamp: bank access, signatory updates, payroll continuity, vendor payment authority, open PO and AR inventory, day-one cash visibility.
• 30-day items, each with a due date inside the first month-end window: COA mapping, vendor master consolidation, customer billing reconciliation, exception process stood up, manual workaround documentation started.
• 90-day items, each with a defined decision date: ERP path decision, approval matrix published and configured, tool stack rationalization plan, cross-system reconciliation cadence running, first combined close planned with a dry run.
• Cross-the-cracks items, owned explicitly by finance and not by HR or IT: sales tax nexus changes, seat audits, intercompany process, benefits and 401(k) timing, change-of-control contract review, bank covenants, audit firm transition.

The framing in how to know what is worth automating applies to each of these in the 30 and 90-day windows. The manual reconciliations you are running during transition are exactly the workflows worth evaluating against the math, before normal operations resume and the workarounds calcify into permanent process. If the consolidated entity is moving onto a single ERP, the Acumatica AP automation pattern and the QuickBooks to Stripe revenue reconciliation are reference shapes for what the cleaned-up version of those reconciliations looks like.

The combined finance function is not built by the checklist. It is built by the discipline of running it, by the people enforcing the handoffs, and by the layer that catches what slips between them. Get the first day right, get the first month-end clean, and the 90-day decisions are made from a position of clarity instead of recovery.

Quick answers

What is post-M&A integration in finance?

The work the finance function owns after legal close to combine two companies into one operating entity. It runs across day one (cash, payroll, signatories), the first 30 days (AP, AR, chart of accounts), and the first 90 days (system consolidation and combined close). It is distinct from corporate development’s integration plan, which is broader and ends earlier.

How long does post-merger financial integration take?

Day one items must clear by close. The first month-end as a combined entity is the real test, 30 to 45 days after close. ERP consolidation lives on the 90-day horizon at the earliest, and running parallel through year-end close is a common path that avoids forcing a mid-year migration on top of a brand-new combined close.

What is the biggest risk in the first 100 days after close?

Items that lack a named owner and a due date. Duplicate payments and missed sales-tax-nexus changes happen because both entities are mid-handoff and no one has explicit ownership of the seam between them. The checklist itself is not the safeguard; the enforcement around it is.