Your ERP isn’t scaling — it’s staging a coup.

An ERP does not suddenly stop scaling one morning.

It usually gives warnings.

More manual exports. More reconciliation. More fields nobody trusts. More conversations that begin with, “Which system are you looking at?”

Then someone concludes the company has outgrown the ERP.

Maybe.

Sometimes the system is the problem.

Sometimes the operating model grew faster than the way the system was configured.

I want to know which one before we begin a very expensive migration.

“The ERP” is rarely one thing

Finance architecture usually includes an ERP, CRM, payroll, billing, expense tools, banking, planning software and whatever operational systems matter to the business.

When reporting breaks, the ERP gets blamed because it sits near the center.

But the failure may be in integration, master data, process ownership or definitions.

I like mapping the flow before blaming the platform.

Where is the transaction created? Where is it approved? Where is it posted? Which system owns the customer, employee, product or account?

The answer is often more revealing than the software logo.

Growth exposes shortcuts that were reasonable earlier

A $10 million company can survive manual work a $100 million company cannot.

One person may know every customer. A spreadsheet may map every department. Month-end allocations may take an hour.

Then volume multiplies.

The shortcut did not become stupid retroactively.

It became too small.

I think this matters because teams can become defensive about old processes.

The right question is not who designed it badly.

It is what the business now requires that the original design never needed to handle.

Master data becomes infrastructure

Customer IDs, vendor records, products, departments, locations, legal entities, chart-of-accounts structure.

At small scale, inconsistencies can be corrected manually.

At larger scale, weak master data contaminates every downstream report.

If CRM and ERP use different customer structures, Finance lives in mapping tables. If departments are created inconsistently, payroll and expense reporting drift. If products are not governed, margin analysis becomes an argument.

I would fix ownership of core dimensions before expecting another system to make them clean.

Integrations fail quietly more often than dramatically

The spectacular failure is easy.

The interface stops. An error appears. Everyone knows.

The quieter failure worries me more.

A subset of transactions does not sync. A new field is not mapped. A status changes upstream and the integration still expects the old value.

Data continues moving.

Just not all of it.

I want interface controls: record counts, dollar totals, exception logs, timestamps and ownership for unresolved failures.

“Automated” should never mean “unreconciled.”

The chart of accounts can become a growth constraint

Companies often ask the GL to answer every management question.

So the chart of accounts expands.

New product? New account. New region? New account. New initiative? Somehow another account.

Eventually the GL becomes a reporting taxonomy instead of an accounting structure.

I prefer using dimensions—department, product, location, customer class—where the system supports them, and keeping the chart of accounts as simple as the accounting requirements allow.

A giant COA can make close and reporting harder without creating better insight.

Customizations should have an expiration question

Custom scripts and workflows can be exactly right.

They can also outlive the problem they solved.

I like maintaining an inventory of material customizations: what it does, why it exists, who owns it, what breaks if it fails.

When the business changes, review whether the customization still belongs.

Otherwise the ERP slowly becomes a museum of every process the company has ever had.

Museums are lovely.

I do not want to close the books in one.

Month-end close is a good stress test

If the system architecture is struggling, close usually knows.

Manual journals increase. Reconciliations take longer. Subledgers do not tie. People wait for interfaces. Finance exports data into Excel to finish what the system cannot.

I like looking at close pain by root cause.

Which steps are system limitations? Which are process timing? Which are data quality? Which are approvals?

That prevents “we need a new ERP” from becoming the answer to every close complaint.

Reporting outside the ERP is not automatically a failure

I do not believe every management report should come directly from the ERP.

FP&A often needs operational and commercial information the accounting system was never designed to hold.

A data warehouse, BI layer or planning platform may be appropriate.

The issue is reconciliation.

Can management reporting tie back to the financial source of truth where it should? Are metric definitions governed? Is the transformation documented?

Moving reporting out of the ERP can be good architecture.

Moving truth into twelve personal spreadsheets is something else.

System performance is different from process performance

A transaction can post in milliseconds while the process takes four days because approvals sit in inboxes.

That is not an ERP-speed problem.

Likewise, an ERP can be technically capable of automation while the company keeps manual controls because nobody redesigned the workflow.

Before replacing software, I want to separate what the system cannot do from what the organization has not configured or adopted.

Those have very different price tags.

Permissions become more important as the company grows

Early-stage companies often begin with broad access because everyone is wearing several hats.

Growth creates a need for stronger segregation of duties.

Who can create a vendor? Change bank details? Approve an invoice? Post a journal? Modify the chart of accounts?

I want role design to evolve with the risk.

An ERP implementation that focuses only on efficiency and ignores permissions can automate a weak control environment beautifully.

Multi-entity growth changes the game

New legal entities, currencies, intercompany transactions and local reporting requirements can expose limitations quickly.

Consolidation may become material. Intercompany eliminations need structure. Shared services need allocation rules.

This is one place where a system genuinely may be too small for the next stage.

I still want the requirements written before vendor demos begin.

“We need something enterprise” is not a requirement.

I would quantify the cost of the current state

ERP projects are expensive and disruptive.

So is staying with a bad architecture.

How many hours are spent on manual reconciliation? How long does close take because of system limitations? How many reporting errors trace to integration? What controls are impossible? What growth initiative cannot be supported?

Put numbers around the pain where possible.

That gives management something better than frustration to compare with the implementation cost.

A migration should not reproduce every old process

This is the great temptation.

Take the existing workflow and rebuild it in the new system.

Now the company has a modern platform running a ten-year-old process.

I like using implementation as a forcing function.

Which approvals still matter? Which reports are used? Which dimensions are necessary? Which customizations can disappear?

The new system should inherit requirements, not rituals.

Finance needs to own requirements, not necessarily the project

IT may lead the implementation. A partner may configure it. Operations may own important workflows.

Finance still needs to be clear about financial requirements.

Close, consolidation, controls, reporting dimensions, audit trail, planning feeds, cash visibility.

I do not want the finance team arriving at user acceptance testing and discovering the new architecture cannot produce the management P&L everyone assumed was obvious.

User acceptance testing should resemble ugly reality

Perfect test cases prove very little.

I want credits, partial payments, contract changes, terminated employees, unusual journals, intercompany activity and whatever else makes the real business annoying.

Systems usually look wonderful in the happy path.

Finance lives in the exceptions.

Test them before go-live.

Parallel runs are expensive for a reason

Running old and new processes together can feel painfully redundant.

It is also how Finance discovers whether the new system produces the same economic result before the old one disappears.

I like clear reconciliation criteria and a defined exit.

Parallel forever is not a migration.

It is two systems.

The system is never really “done”

This part of the old post I still believe.

Businesses change. Products change. reporting needs change. controls change.

An ERP needs governance after implementation: ownership, change control, integration monitoring, master-data standards and periodic cleanup.

Otherwise today’s clean build becomes tomorrow’s collection of workarounds.

Scaling is really about preserving trust as complexity grows

I do not need every process to remain simple.

Growth creates legitimate complexity.

I need the financial architecture to remain explainable and controlled.

Transactions should land where expected. Systems should reconcile. Management reporting should have lineage. Permissions should reflect risk.

When those things begin failing, the ERP may be part of the answer.

Just do not let a software purchase substitute for diagnosing the system the company has actually built around it.

Sometimes the ERP is staging a coup.

Sometimes we handed it the kingdom one workaround at a time.

System-of-record language needs to be specific

Companies love saying a platform is “the system of record.”

For what?

The ERP may be the system of record for posted financial transactions. CRM may own commercial opportunity data. HRIS may own employee status. Billing may own subscription schedules.

I am comfortable with multiple authoritative systems if ownership is explicit and the integrations are controlled.

I become uncomfortable when “system of record” means “the system we trust unless another one has the number we prefer.”

Data warehouses do not eliminate reconciliation

A modern data stack can make reporting much more flexible.

It can also move transformation farther from the finance users consuming the result.

If a management metric is calculated in the warehouse, I want Finance to understand the definition, source fields and reconciliation to financial actuals where relevant.

The SQL can live with the data team.

The economic meaning cannot.

Finance should not outsource understanding because the calculation moved out of Excel.

Planning-system integrations deserve the same discipline

A planning platform is only as current as the feeds entering it.

If actuals refresh late, headcount does not sync, or CRM pipeline definitions change, the forecast can become stale while the interface still looks current.

I like visible refresh timestamps, reconciliation controls and ownership for each major feed.

The prettier the planning environment, the easier it is to forget that data still has to arrive correctly.

Technical debt should be visible to management

Finance teams often carry system debt quietly because they can work around it.

Manual upload. Mapping file. Extra reconciliation. Another macro.

Each workaround seems small.

Together they create key-person dependency, close risk and slower analysis.

I like maintaining a simple backlog of material finance-system debt with estimated effort and business consequence.

That turns “our systems are messy” into choices management can prioritize.

ERP projects fail when ownership ends at go-live

After implementation, somebody has to own configuration decisions, enhancement requests, master data and process standards.

Without governance, departments optimize locally.

A new field appears. A workflow changes. An integration is modified. Finance discovers the downstream effect later.

I want a lightweight change process that asks what financial reporting, controls and integrations are affected before material changes move into production.

Boring governance is cheaper than exciting remediation.

I would rather fix one root cause than automate five workarounds

This is a useful filter when AI and automation enter the conversation.

If Finance manually corrects customer mappings every month, we could build an AI tool to suggest the mappings.

Maybe that helps.

Or we could fix customer-master ownership upstream.

Automation is powerful.

It should not make us emotionally attached to a broken process because the workaround became clever.

The migration decision should include organizational capacity

A company can genuinely need a new ERP and still be unprepared to implement one.

Who will define requirements? Clean master data? Test workflows? Make decisions quickly? Train users? Maintain normal close while the project runs?

Implementation consumes internal attention, not only consulting dollars.

I want that capacity in the business case.

A theoretically perfect project can become very expensive if the people needed to make it work are already operating at 110%.

Good architecture makes future questions cheaper

This is the payoff I care about.

Management asks for margin by product and Finance can answer because product dimensions are governed. The company adds an entity and consolidation already has a structure. FP&A wants actuals by department and the HR-to-ERP mapping is controlled.

Good systems do not merely process today’s transactions.

They reduce the cost of tomorrow’s questions.

That is what scaling means to me.

Not buying the biggest platform available.

Building financial infrastructure that can absorb more complexity without requiring Finance to reinvent truth every month.