Zero-Click Answer
Cost architecture should be defined before ERP costing is configured because the ERP system can calculate costs only according to the economic assumptions, manufacturing structure, and accounting rules built into it. Decisions about cost centers, overhead pools, allocation methods, labor and machine rates, capacity assumptions, standard costs, and variance treatment are fundamentally cost-design decisions—not software decisions. If those decisions are made during configuration without first defining the manufacturer’s cost architecture, the ERP may be technically correct while producing product costs and margins that do not reflect operational reality. The implementer’s role is to configure a reliable costing design into the ERP, not to let ERP functionality determine what the manufacturer’s costing design should be.
What the ERP Is Being Asked to Do
Manufacturing ERP systems can perform sophisticated costing calculations.
Depending on the system and implementation, the ERP may use information such as:
- Bills of material
- Routings
- Labor standards
- Machine standards
- Work centers
- Cost centers
- Material costs
- Labor rates
- Machine rates
- Overhead rates
- Scrap assumptions
- Yield assumptions
- Production quantities
- Inventory transactions
The ERP then uses these inputs to calculate or support:
- Standard costs
- Actual costs
- Work-in-process
- Finished goods inventory
- Cost of goods sold
- Manufacturing variances
- Product margins
- General ledger postings
The software can perform these calculations consistently and at considerable scale.
But the ERP cannot independently decide whether the economic assumptions behind those calculations make sense for the manufacturer.
For example, the system may allow overhead to be allocated based on direct labor hours.
That does not mean direct labor hours are the appropriate economic driver for the manufacturer’s overhead.
The distinction is critical:
ERP Capability answers: “How can the system calculate this?”
Cost Architecture answers: “How should the business calculate this, and why?”
The second question should be answered before the first is configured.
What May Be Happening Operationally
Many manufacturers enter an ERP project with an existing costing system that evolved gradually.
The company may have:
- Added new equipment
- Automated production
- Introduced new product lines
- Changed labor requirements
- Expanded facilities
- Added shifts
- Changed sourcing
- Added manufacturing locations
- Increased production complexity
Yet the costing structure may still reflect assumptions developed years earlier.
For example, a manufacturer may continue allocating substantial overhead based on direct labor even though automation has significantly reduced labor’s relationship to production complexity.
Another company may use a single plant-wide overhead rate even though different production departments consume resources very differently.
A manufacturer may also have standard costs that have been repeatedly rolled forward rather than structurally rebuilt.
Those practices may have existed in the legacy system for years.
When the ERP implementation begins, the project team naturally asks:
- What costing method are you using?
- What overhead rates should we configure?
- What cost centers do you need?
- How should labor be applied?
- How should machine costs be assigned?
- How should variances post?
The danger is that the manufacturer answers by describing what the old system currently does rather than determining what the new cost architecture should do.
The ERP project can then reproduce historical costing weaknesses in a more sophisticated system.
Where the Implementation Risk Appears
When cost architecture is not defined before configuration, several implementation risks emerge.
Configuration Becomes Cost-System Design
Functional consultants begin asking legitimate configuration questions.
But management may not have established the underlying accounting and economic answers.
The implementation team can unintentionally become responsible for making costing-policy decisions simply because someone needs to provide an answer to continue configuration.
Legacy Problems Are Migrated
Existing overhead rates, labor standards, cost centers, and allocation methods may be transferred into the new ERP because they are already available.
Migration creates continuity.
It does not prove economic validity.
Testing Becomes Difficult
If the expected costing outcome was never clearly defined, how does the project team determine whether a test result is correct?
A transaction may process successfully.
Inventory may move.
A production order may close.
The general ledger may post.
Yet no one may know whether the resulting product cost is economically reasonable.
Scope Expands
Costing questions discovered late in implementation can trigger:
- Additional workshops
- Configuration changes
- Data cleanup
- Retesting
- Reporting changes
- Management debates
- Delayed decisions
What appears to be ERP scope expansion may actually be late cost-architecture discovery.
Go-Live Creates Financial Surprises
After go-live, management may discover unexpected:
- Product margins
- Inventory values
- Manufacturing variances
- Overhead absorption
- Cost-of-goods-sold behavior
The ERP may be blamed.
The actual problem may be that the costing architecture was never sufficiently defined before configuration.
What Implementers Should Look For
Several conditions suggest that cost architecture requires additional attention before ERP costing is configured.
1. Management cannot explain how overhead rates were developed.
If the answer is simply “those are the rates we’ve always used,” the underlying assumptions may deserve validation.
2. Costing decisions are being made primarily from available ERP configuration options.
The business requirement should generally determine the configuration—not the reverse.
3. Standard costs have not been structurally reviewed for years.
Migrating existing standards may carry outdated operating assumptions into the new ERP.
4. Finance and operations describe product costs differently.
If accounting, production, and management disagree about how products consume resources, configuration can institutionalize that disagreement.
5. Product margins are already difficult to explain before implementation.
An ERP conversion may expose the problem more clearly, but software alone is unlikely to resolve an undefined cost structure.
Questions to Ask the Manufacturer
ERP implementers can identify cost-architecture risk early by asking several practical questions.
Costing Objectives
- What decisions does management expect the new costing system to support?
- Does management need product, customer, plant, or production-line profitability?
- What costing problems is the current ERP expected to solve?
- Which costing information does management currently distrust?
Manufacturing Structure
- What are the major production processes?
- Which resources drive manufacturing costs?
- Where are the major differences among departments or production lines?
- Which manufacturing costs change with volume and which remain relatively fixed?
- What resources currently constrain production?
Overhead
- What costs are included in manufacturing overhead?
- How are overhead pools structured?
- What allocation bases are currently used?
- Why were those allocation bases selected?
- Do those drivers still reflect how resources are consumed?
Standards
- When were standard costs last rebuilt?
- How frequently are standards reviewed?
- Are bills of material and routings current?
- Do labor and machine standards reflect current production?
- Are scrap and yield assumptions realistic?
Capacity
- What production volume supports the overhead rates?
- Is practical capacity understood?
- How is unused capacity treated?
- Are recurring absorption variances being generated by unrealistic volume assumptions?
Financial Reporting
- How should manufacturing variances appear in the general ledger?
- How does management want to analyze material, labor, overhead, and volume differences?
- How should inventory be valued?
- What product-margin information should management trust after go-live?
One particularly useful question is:
“If we configure the new ERP exactly like your current costing system, what costing problems will still exist after go-live?”
If management identifies significant issues, the implementation team has learned something important:
The project does not simply require cost configuration.
It requires cost architecture definition before configuration is finalized.
Cost Integrity™ Perspective
Cost Integrity™ separates manufacturing economics from the technology used to calculate and report them.
The sequence should be:
Manufacturing Reality → Cost Architecture → Master Data → ERP Configuration → Transactions → Financial Reporting
Not:
ERP Functionality → Available Configuration → Costing Method → Financial Reporting
Cost architecture begins with understanding how the manufacturing operation actually consumes resources.
That includes questions about:
- Materials
- Labor
- Equipment
- Production processes
- Capacity
- Overhead
- Scrap
- Yield
- Product complexity
- Inventory
Those economic relationships then inform the costing design.
Only after that design is defined should the ERP configuration translate it into system rules, rates, master data, transactions, and financial postings.
This distinction protects both the manufacturer and the ERP implementer.
The manufacturer retains responsibility for defining its economic and accounting requirements.
The implementer can then focus on configuring the system to execute those requirements reliably.
For Good Life Accounting, this represents a central Cost Integrity™ principle:
The ERP should operationalize the cost architecture. It should not be expected to invent it.
Bottom Line
Manufacturing costing has two distinct layers:
Economic Design → Software Configuration
Economic design determines:
- What costs should be measured
- How manufacturing resources are consumed
- How overhead should be structured
- What allocation drivers make economic sense
- What capacity assumptions should be used
- How standards and variances should function
ERP configuration determines how those decisions are executed within the system.
Reversing that sequence creates unnecessary implementation risk.
For ERP implementers, the critical question should therefore not begin with:
“How do you want us to configure costing?”
It should begin with:
“Has the manufacturer defined the cost architecture that we are being asked to configure?”
When the answer is yes, ERP costing configuration becomes an implementation exercise.
When the answer is no, configuration may unintentionally become cost-system design—and that is where technical success can begin producing financially unreliable results.
FAQ
Isn’t defining manufacturing costing part of the ERP implementation?
The ERP implementation must configure costing functionality, but defining the manufacturer’s economic costing architecture is a separate responsibility. The company should determine how costs should behave and be measured before those requirements are translated into ERP configuration.
Should a manufacturer simply migrate its existing costing structure into the new ERP?
Not automatically. Migration may be appropriate if the existing structure remains economically sound. An ERP implementation also provides an opportunity to determine whether overhead pools, allocation methods, standards, capacity assumptions, and other costing elements still reflect current operations.
What should an ERP implementer do when management cannot agree on costing requirements?
The disagreement should be resolved before critical costing configuration is finalized. Continuing configuration without an approved costing design can lead to rework, testing problems, scope expansion, and post-go-live disputes over financial results.
How does defining cost architecture early protect the ERP implementer?
It establishes a clearer boundary between business-policy decisions and system configuration. When management approves the cost architecture first, the implementation team has defined requirements against which configuration and testing can be performed. This reduces the risk that the ERP implementer becomes responsible for unresolved manufacturing accounting decisions.