Building an Invoice Management System From Scratch After a Carve-Out

What Happens to Accounts Payable in a Carve-Out?

Corporate restructuring gets discussed in terms of legal entities, headcount and transitional service agreements. What rarely makes the steering-committee slide is that somebody in finance now has to process supplier invoices on Monday with no system to process them in.

This is a specific and underrated failure mode. A finance function inside a larger group typically inherits its payables infrastructure: a system someone else selected, configured and maintains. When the entity separates, that infrastructure stays behind. The team keeps the obligations — suppliers still invoice, approvers still need to approve, auditors still need evidence — and loses the machinery.

The pressure is compounded by sequencing. Carve-outs run to legal deadlines, not software selection cycles. A finance manager handed the task of replacing an invoice management system is usually given weeks, while the same decision in a stable organisation would take two quarters of evaluation. Research from Deloitte on finance transformation consistently identifies this compression as the main driver of poor system choices during separation events.

Why Does the In-House Invoice System Never Come With You?

Groups that built bespoke payables tooling built it for the group. The software is usually entangled in ways that only surface during separation:

• It sits on the parent’s infrastructure, under the parent’s security model and licensing.
• It encodes the parent’s chart of accounts, entity structure and approval hierarchy.
• It was maintained by developers who remain employees of the parent.
• Its data model assumes group-level consolidation that no longer applies.

Even where goodwill exists on both sides, a transitional service agreement for internal software is awkward. The parent has no commercial interest in supporting a system for a company it no longer owns, and every month of extended access delays the separation it is trying to complete.

The result is that the carved-out team knows precisely what good looks like — they used it daily — but cannot have it. That combination of clear requirements and zero infrastructure is unusual, and it changes how the replacement should be selected.

Should You Rebuild In-House or Buy an Invoice Management System?

The instinct to rebuild is strong, particularly where the inherited system was well liked and the organisation has engineering capability. It is usually the wrong call, and the carve-out itself is the argument against it.

The final row is the one that matters. A carve-out is a live demonstration of what happens when critical finance infrastructure is bespoke and owned by someone else. Rebuilding bespoke software reproduces that risk with a different owner. Unless invoice handling is a genuine source of competitive advantage — and for an investment firm, a professional services business or a holding company, it is not — the maintenance liability outweighs the fit.

Guidance from the Association for Financial Professionals on technology selection makes a related point: the hidden cost of bespoke finance tooling is not the build, it is the decade of small changes afterwards, each of which requires engineering attention that a lean finance team cannot command.

What Does a Carved-Out Finance Team Actually Need on Day One?

The most common error is attempting to replicate the full inherited capability set before the entity starts trading. Scope discipline is what makes the deadline achievable.

Deferring payment disbursement surprises people, but it is usually correct. Bank and payment-rail onboarding runs on the provider’s compliance timeline, not yours. A system that captures, codes, approves and archives invoices delivers most of the control value while payment continues through existing banking channels for a quarter.

How Do You Rebuild Approval Logic You Did Not Design?

The inherited approval matrix is rarely documented accurately. What exists on paper is the policy; what happens in practice is the behaviour. Rebuild from the behaviour.

Three patterns routinely appear in the gap between the two. First, category-based routing that ignores amount thresholds — professional fees such as legal, consulting and research escalating to the chief executive regardless of value, while larger administrative costs settle at finance-head level. Second, informal delegation, where a named approver has in practice been approving on someone else’s behalf for years. Third, document preconditions, where an approver will not act until a contract or engagement letter is attached to the record.

None of these survive a migration that works from the policy document alone. The practical method is to extract the last six to twelve months of approval history from the inherited system and reconstruct the real rules from who actually approved what. Our guide to approval workflow bottlenecks and manual routing covers how to read those patterns, and approval delegation and fallback approvers addresses the informal-delegation problem specifically.

This is also the moment to fix what was broken. A carve-out is the one point at which approval design is genuinely open, because nobody is defending a configuration they built. Latency that was tolerated for years — described in detail in our analysis of invoice approval workflow latency and its cost — can be designed out rather than inherited.

Why Exportable Audit Trails Matter More After a Carve-Out

A new entity has no history. Everything it asserts about its own controls in year one must be evidenced from primary records, and the consumers of that evidence are external: statutory auditors, fund administrators, lenders, investment committees and prospective investors conducting due diligence.

None of them work inside your accounts payable system. This makes a distinction that sounds pedantic and is not: the difference between an audit trail you can view and one you can export. A change log rendered on screen satisfies an internal curiosity. An audit request asks for the approval history of forty specific invoices as an attachment, and a system that cannot produce that file turns a ten-minute task into a week of screenshots.

The requirements worth confirming during evaluation:

• Every field change, approval action and timestamp is captured with the acting user’s identity.
• The trail covers vendor master changes, not just invoice changes.
• Export is available as both PDF for individual records and spreadsheet for bulk ranges.
• Export is self-service, not a support ticket to the vendor.
• Attachments stored against vendors and invoices export alongside the metadata.

Standards guidance from IFAC and the Institute of Management Accountants both treat retrievability as part of the control, not an administrative convenience. A control that cannot be demonstrated to a third party is difficult to distinguish from a control that does not exist. Our write-up on audit trail and invoice documentation requirements goes deeper on the evidence formats auditors actually request.

What Does a 90-Day AP Stand-Up Look Like?

The extract phase is the one that cannot be recovered if missed. Access to the parent system ends on a legal date, and the historical invoice coding — the dataset that lets automated general ledger coding work immediately rather than after months of correction — is gone with it. Teams that treat week one as planning time rather than extraction time pay for it for a year.

The parallel run is frequently skipped under deadline pressure and frequently should not be. It is the only point at which the reconstructed approval rules can be validated against the real ones while the real ones still exist.

How Peakflo Helps

Peakflo’s accounts payable automation is built to operate in exactly the state a carved-out entity finds itself in: no accounting system selected, no payment rail connected, and a deadline. Supplier invoices arrive at a dedicated capture address, AI extracts header and line-item data, and general ledger codes are assigned from a chart of accounts imported as a spreadsheet and trained on whatever historical coding the team managed to export. No integration is required for any of that to work, and the fully reconciled records export cleanly when an accounting platform is eventually chosen.

Approval rules are configured by the finance team rather than requested from engineering, which matters when the real routing logic only becomes clear during the parallel run. Category-based rules, multi-step chains, document preconditions on vendor approval and mobile approval for executives who never open a laptop are all configuration rather than custom development. The change log captures every field change, approval and vendor-master amendment, and exports to PDF or spreadsheet without raising a support request. Phase-two capabilities — end-to-end payment automation and accounting integrations including Xero and NetSuite — are separate modules that activate when the entity is ready rather than prerequisites for go-live. If you are working to a separation deadline, request a demo and bring your day-one capability list.

Our Verdict

A carve-out is a bad time to make a software decision and an excellent time to make a scoping decision. The teams that come through it well are not the ones that evaluated most thoroughly; they are the ones that drew a hard line between what must work on day one and what can wait a quarter.

Buy rather than rebuild, in almost every case. The carve-out is itself the evidence: bespoke finance infrastructure owned by someone whose incentives may diverge from yours is precisely the position that created the problem. Reproducing it with a different owner is not a solution.

Extract before you select. The historical invoice coding sitting in the parent system is worth more than any feature comparison, because it is what makes automated coding useful immediately rather than eventually, and it has a hard expiry date.

Where rebuilding genuinely makes sense is narrow: the entity has material engineering capacity it is not otherwise using, invoice handling is a differentiator rather than overhead, and the separation timeline is unusually generous. For an investment firm, a holding company or a professional services business, none of those conditions typically hold.

Conclusion

The invoice management problem in a carve-out is not really a technology problem. It is a scoping and sequencing problem wearing technology clothing. Finance teams fail at it by trying to replicate three years of accumulated configuration in six weeks, and succeed at it by accepting that the first version will be smaller than what they had and better than what they would have built.

Start with the extract. Scope to day one. Buy rather than build. Validate the approval rules against observed behaviour while the old system still exists to be observed. And confirm the audit trail leaves the system as a file, because the first auditor who asks will not accept a screenshot.

Frequently Asked Questions

How long does it take to implement an invoice management system after a carve-out?

A focused scope of invoice capture, vendor approval and multi-level routing can be live in four to eight weeks. The longer tail is historical data migration and approval-rule validation. Teams that defer payment disbursement and ERP integration to a second phase reach a working state far faster than those attempting everything at once.

Should a carved-out entity rebuild its invoice system in-house?

Rarely. Rebuilding in-house recreates exactly the dependency the carve-out exposed: bespoke software owned by someone whose priorities may diverge from yours. Unless invoice handling is a genuine competitive advantage, a configurable commercial platform removes the maintenance liability and the single-developer risk.

What should finance export from the parent system before losing access?

Approval rules and delegation matrices, the full vendor master with supporting documents, the chart of accounts, and at least six months of historical invoice coding. The historical coding is the most commonly forgotten item and the most valuable, because it is the training data that lets AI general ledger coding work from day one.

Can an invoice management system work before an accounting system is chosen?

Yes. A standalone invoice management system can capture, code, route and archive invoices with no accounting integration at all. The chart of accounts is imported as a spreadsheet, and the fully approved records are exported when an accounting platform is eventually selected.

Why does an exportable audit trail matter more after a carve-out?

A newly separated entity has no track record of its own. First-year audits, investor due diligence and board reporting all demand documentary evidence, and those consumers sit outside the accounts payable tool. An audit trail that can only be viewed on screen fails the moment someone asks for it as an attachment.

Does a small finance team need multi-level approval at all?

Yes, and often more than a large one. Lean teams have less segregation of duties by headcount, so the approval chain is doing more of the control work. Benchmarking from APQC shows small finance functions carry proportionally higher payables risk precisely because fewer people touch each transaction.