How should a finance leader think about the finance systems stack?

All-in-one suites win on native cohesion and one throat to choke; best-of-breed wins on depth in each function and avoids being held hostage to a suite's weakest module. AI nudges toward best-of-breed in two ways: focused vendors ship AI capability faster in their domain, and better integration/agent tooling lowers the cost of connecting specialized tools. But integration debt is real - the trade is depth-and-speed versus connection-and-maintenance, and the right answer depends on where your pain and complexity actually are.

Add a layer when the ERP is fine as a system of record but its AP work is the bottleneck - you get the capability fast without a disruptive core swap, and the layer survives a future ERP change. Upgrade the ERP when the core itself can't carry your complexity (entities, dimensions, reporting), where AP is one symptom of a too-small ledger. The decision framework: is the pain in the work (add a layer) or in the foundation (upgrade the core)?

Build for genuinely unique workflows where no product fits and you can sustain the maintenance; buy for solved problems (capture, approval, matching) where a vendor amortizes R&D and upkeep across thousands of customers. The hidden cost of build is perpetual maintenance and key-person risk - most finance automation is a buy, with build reserved for true differentiation.

Roughly: at $10M, a capable SMB/mid ERP and basic AP discipline; at $50M, a dedicated AP/spend layer, real approvals, multi-entity handling, and close discipline; at $250M, mature best-of-breed layers (AP, close management, FP&A), strong integration governance, and a finance-systems owner. Buy ahead of the pain by one step, not three.

ERP core (system of record) -> dedicated AP/spend layer (the procure-to-pay work) -> close-management and reconciliation tools -> FP&A/planning -> and increasingly AI agents across them, all tied together by integrations with one system owning each data object. The art is clean boundaries and minimal integration debt.

Too many is when integration debt and tool overlap cost more than the specialization buys - symptoms include duplicated data across tools, reconciliation between systems that should agree, nobody owning the stack, and users unsure where to do a task. The trigger to consolidate is overlap and integration burden, not the raw count.

Finance owns the requirements and outcomes; IT owns security and infrastructure; the integrations and day-to-day administration increasingly justify a dedicated finance-systems role as the stack grows. Hire one when no single person can explain how the stack fits together - usually in the mid-market scale-up.

"Free" bundled modules still carry the manual-labor tail (correction, headcount, close delays) and often lag dedicated tools. Evaluate on three-year total cost including that labor, and on whether the bundled module actually solves your AP pain. Bundle discounts are real value only if the module is genuinely good enough for your complexity.

Integration debt is the accumulating cost of connections between systems - each integration must be maintained through both endpoints' updates, and as tools multiply the connections grow faster than the tools. It accumulates from custom point-to-point builds, undocumented mappings, and unowned connectors, and it surfaces as silent breakages and rising maintenance hours.

Agents are augmenting work (capture, coding, anomaly detection, drafting) now; fully autonomous replacement of governed finance functions is not here and won't be soon, because finance requires human-in-control judgment and audit accountability. Do now: adopt AI that removes manual work under human review. Wait on: betting the stack on a fully autonomous agent that doesn't yet exist.

Assess vendor viability (funding, customer base, longevity), data-exit terms (can you leave with your data?), and how concentrated your dependence is. Mitigate with strong data-ownership/egress contract terms and an ERP-abstracted layer that's re-pointable, so a vendor change is disruptive but not catastrophic.

One ERP everywhere simplifies AP (single system, uniform process) but forces every entity onto one model and is costly to achieve via acquisition. Hub-and-spoke keeps light ledgers at subsidiaries with consolidation at HQ - flexible but multi-ERP, which makes a unifying AP layer across the spokes especially valuable for one process and one spend view.

Stampli is the best-of-breed AP/spend layer in this architecture - it lets the ERP stay the system of record while a focused, ERP-native platform runs procure-to-pay, so finance gets domain depth and AI capability without ripping out the core or waiting on a suite's roadmap. Because Stampli mirrors the ERP and supports 70+ of them, it reduces integration debt rather than adding a parallel ledger, and it carries forward as the stack evolves.