How Late Invoices, Backdated Transactions and Production Costs Can Change Inventory Value, Product Cost and COGS
The Cost Was Correct Yesterday. Why Is It Wrong Today?
Imagine this.
Your company purchases a raw material for ₹100 per KG.
The material is received into the warehouse. The inventory is updated. The material is consumed in production. A finished product is manufactured and transferred to the finished goods warehouse.
Everything looks correct.
A few days later, the supplier invoice arrives.
The actual price is ₹110 per KG.
Now Finance has a problem.
The material has already been consumed.
It has already become part of a production order.
The production order has already created finished goods.
Some finished goods may still be in inventory.
Some may already have been sold.
So the obvious question is:
Where should the additional ₹10 per KG go?
Should it remain as a purchase price difference?
Should it increase the production cost?
Should it change the finished goods value?
Should it affect COGS?
Should it be distributed across inventory and sold products?
And most importantly:
Can the ERP system trace the difference back through the transactions and recalculate the affected costs correctly?
This is where costing recalculation becomes critical.
After years of working on ERP implementations across procurement, inventory, MRP, manufacturing, finance and costing, I have seen variations of this problem many times.
The individual transaction rarely looks complicated.
The problem appears when you follow the transaction through the entire ERP.
Does This Sound Familiar?
Your business may have experienced something like this:
- The material was received at one price.
- The supplier invoice arrived later at another price.
- The material was already consumed.
- Production was already completed.
- The finished product was already transferred to stock.
- Some of the finished product was already sold.
- Finance discovered the difference during month-end closing.
- Someone opened an Excel sheet to calculate the impact manually.
Now the question becomes:
“How do we correct the cost without disturbing the entire inventory and accounting history?”
If your team has faced this situation, you are not alone.
This is not simply an accounting problem.
It is an ERP costing architecture problem.
What Is Costing Recalculation?
In simple language, costing recalculation means:
Recalculating inventory or product costs when new, corrected, or additional cost information becomes available.
The important point is that the cost of an item is not always completely known at the moment the physical transaction takes place.
A typical procurement and manufacturing process might look like this:
Purchase Order → Goods Receipt → Inventory → Consumption → Production → Finished Goods → Sales
But the financial information may arrive in a different sequence:
Purchase Order → Goods Receipt → Consumption → Production → Finished Goods → Supplier Invoice → Freight/Landed Cost → Cost Adjustment
The physical movement has already happened.
The final cost becomes known later.
That timing difference is one of the main reasons costing recalculation is required.
Why Does the Original Cost Become Incorrect?
Many users assume that once an inventory transaction is posted, its cost is final.
In practice, that is not always true.
Consider a simple example.
A company purchases 1,000 KG of Raw Material A at ₹100/KG.
The material is received:
1,000 × ₹100 = ₹100,000
The material is then consumed in production.
Later, the supplier invoice arrives at:
₹105/KG
The actual purchase value is now:
1,000 × ₹105 = ₹105,000
There is a ₹5,000 difference.
But where is the material?
It may no longer be sitting in the warehouse.
It may have been consumed.
And if it was consumed, it may already have become part of a production order.
That production order may have created finished goods.
The finished goods may still be in stock—or may already have been sold.
The ₹5,000 difference has therefore potentially travelled through the ERP.
This is why costing cannot always be treated as a single transaction.
It is a chain of financial consequences.
Real-Life Manufacturing Example: The Invoice Arrives After Production
Let’s take a more realistic manufacturing example.
A company manufactures a product called ABC.
The BOM contains:
- RM-A – 2 KG
- RM-B – 1 KG
- RM-C – 0.5 KG
The company plans and produces 3,000 units of ABC.
At the time of production, the ERP calculates the material cost using the costs available in inventory.
Production is completed.
Finished goods are transferred to the warehouse.
A week later, the supplier invoice for RM-A arrives.
The actual purchase price is higher than the cost originally used.
Now the ERP has to answer several questions:
- Which purchase transaction caused the difference?
- How much of RM-A is still in inventory?
- How much was consumed?
- Which production orders consumed it?
- Which finished products were created?
- Are those finished products still in stock?
- Have some already been sold?
- How should the additional cost be distributed?
- What accounting impact should be generated?
This is where a properly designed costing engine becomes important.
The ERP should not simply say:
“RM-A cost changed.”
It should understand:
“RM-A cost changed, and that change may affect everything that consumed RM-A after the relevant transaction.”
Follow the Cost Through the ERP
This is the part of costing that is often misunderstood.
Consider this chain:
Supplier Invoice
↓
Raw Material Cost
↓
Inventory
↓
Material Consumption
↓
Production Order
↓
WIP
↓
Semi-Finished Product
↓
Finished Product
↓
Sales / COGS
A cost difference introduced at the beginning can therefore have consequences much later in the process.
For a simple trading company, the impact may stop at inventory.
For a manufacturing company, the impact can continue through multiple production levels.
That is why manufacturing ERP costing is more complicated than simply calculating the BOM cost.
Moving Average Cost Makes Recalculation Even More Important
Moving average costing is commonly used when organizations want inventory cost to reflect changing procurement costs.
A simplified formula is:
New Average Cost =
(Existing Inventory Value + New Receipt Value) ÷
(Existing Quantity + New Receipt Quantity)
For example:
Opening Stock
100 KG @ ₹100
Value = ₹10,000
New Receipt
100 KG @ ₹120
Value = ₹12,000
Total
200 KG
Total Value = ₹22,000
Therefore:
Moving Average Cost = ₹22,000 ÷ 200 = ₹110/KG
The material now carries an average cost of ₹110/KG.
But what happens if a transaction is entered later with an earlier transaction date?
That is where things become more complicated.
The Backdated Transaction Problem
Backdated transactions are common in real businesses.
For example:
A warehouse physically receives material on 5 September, but the GRN is entered on 12 September.
Or the supplier invoice is dated 4 September, but Finance enters it on 20 September.
Or a purchase return that physically happened on 8 September is entered into the ERP on 18 September.
Now consider this sequence:
| Date | Transaction | Quantity | Cost |
| 1 Sep | Opening Stock | 1,000 | ₹100 |
| 5 Sep | Issue | 600 | — |
| 8 Sep | Receipt | 500 | ₹120 |
| 12 Sep | Backdated Receipt | 300 | ₹90 |
The transaction entered on 12 September may logically belong before transactions that have already been processed.
If the costing method depends on transaction sequence, the ERP may need to revisit the affected transactions.
This is one of the reasons that backdated inventory transactions should not be treated as harmless data-entry corrections.
They can change the cost history.
When ERP Costing Becomes an Excel Exercise
I have seen another common pattern during ERP implementations.
Finance discovers a costing difference.
The ERP does not provide a clear explanation.
So someone exports:
- Purchase transactions
- Goods receipts
- Inventory issues
- Production orders
- Finished goods receipts
- Sales transactions
into Excel.
Then the team starts manually calculating the impact.
One spreadsheet becomes two.
Two become five.
Eventually someone asks:
“Which number is correct?”
At this point, the problem is bigger than an accounting adjustment.
If Finance has to manually reconstruct the cost flow outside the ERP, it is often a sign that the ERP’s costing process, traceability, or configuration needs to be reviewed.
An ERP should reduce this manual reconstruction—not create another reason for it.
Costing Recalculation in Manufacturing
Manufacturing makes costing significantly more complex because product cost can contain many components.
A finished product may include:
- Raw materials
- Semi-finished products
- Direct labour
- Machine costs
- Electricity
- Production overhead
- Subcontracting
- Packaging
- Freight
- Quality-related costs
- Other manufacturing expenses
Therefore:
Product Cost ≠ BOM Material Cost Alone
Consider:
Finished Product ABC
Material Cost = ₹500
Labour Cost = ₹100
Machine Cost = ₹75
Overhead = ₹50
Subcontracting = ₹25
Total Production Cost = ₹750
Now suppose actual machine activity cost is calculated at month end and changes from ₹75 to ₹90.
The actual cost becomes:
₹500 + ₹100 + ₹90 + ₹50 + ₹25 = ₹765
The difference is:
₹15 per unit
If the company produced 20,000 units:
20,000 × ₹15 = ₹300,000
A ₹15 difference per unit has now become a ₹3 lakh costing adjustment.
This is why product costing cannot always be treated as a static number.
WIP: The Cost Between Two Worlds
Work in Progress is another important part of the costing story.
Imagine a production order starts in September and finishes in October.
During September:
- Raw materials are consumed.
- Labour is recorded.
- Machine activity is recorded.
- Production overhead is allocated.
But the finished product does not yet exist in the finished goods warehouse.
Where is the cost?
In WIP.
At month end, the ERP needs to determine:
How much cost belongs to the unfinished production order?
When the production order is completed, the system then needs to determine:
How much cost should move from WIP to the finished product?
If additional costs become available later, the production order cost may need to be recalculated.
This becomes particularly important in organizations with hundreds or thousands of production orders.
Multi-Level Manufacturing Makes the Problem Bigger
Consider a three-level manufacturing process:
Level 1 — Raw Materials
↓
Level 2 — Semi-Finished Product
↓
Level 3 — Finished Product
Suppose RM-A becomes more expensive.
That may change the cost of the semi-finished product.
The semi-finished product is then consumed to manufacture the finished product.
The cost impact can therefore move through multiple levels:
RM Cost Change
→ SFG Cost Change
→ FG Cost Change
→ Inventory Valuation Change
→ COGS Change
This is often referred to as cost roll-up or multi-level costing.
The ERP should therefore understand the dependency chain rather than treating each product as an isolated item.
This becomes particularly important when manufacturing contains multiple stages, subcontracting, intermediate products, and shared components.
What Happens When the Finished Product Has Already Been Sold?
This is where the business impact becomes very clear.
Suppose:
Finished Product Cost = ₹750
The company sells:
10,000 units
Initial COGS:
10,000 × ₹750 = ₹7,500,000
Later, actual costing determines that the correct cost should have been:
₹780
Difference:
₹30 per unit
For 10,000 units:
10,000 × ₹30 = ₹300,000
But those units are no longer in inventory.
They have already been sold.
Therefore, the ERP needs to determine the appropriate treatment of the difference based on the organization’s costing method and accounting policy.
This may involve:
- Inventory
- COGS
- Cost variance
- Production variance
- Price difference
- Financial accounts
That is why costing cannot be designed independently from accounting.
Inventory and accounting must remain connected.
A Small Cost Difference Can Become a Large Business Difference
Let’s look at this from management’s perspective.
Suppose:
Selling Price = ₹1,500
Initially calculated product cost:
₹1,000
Expected margin:
₹500
The business believes it has approximately a 33.3% gross margin.
But actual costing later determines:
Actual Cost = ₹1,150
The actual margin becomes:
₹350
The difference is:
₹150 per unit
Now imagine that the company sells 50,000 units.
₹150 × 50,000 = ₹7,500,000
That is ₹75 lakh.
The original problem looked like a ₹150 costing difference.
At business scale, it became a ₹75 lakh issue.
This is why costing recalculation is not merely a finance department concern.
It can influence pricing, profitability analysis, product decisions and management reporting.
What Happens If Costing Recalculation Is Ignored?
The consequences can extend across the ERP.
1. Incorrect Inventory Valuation
Inventory may not reflect the intended cost under the company’s valuation method.
2. Incorrect Product Cost
Management may believe that a product costs ₹500 when the actual cost is ₹540.
3. Incorrect Gross Margin
If COGS is incorrect, gross margin is also affected.
4. Incorrect Product Profitability
Products may appear more profitable—or less profitable—than they actually are.
5. Unexplained Cost Variances
Finance may see differences between purchasing, inventory, production and accounting.
6. Difficult Month-End Closing
The finance team may spend days reconciling inventory and accounting manually.
7. Loss of Confidence in ERP Reports
This is perhaps the most serious problem.
Once users stop trusting ERP costing reports, they start maintaining parallel spreadsheets.
And once Excel becomes the source of truth, one of the biggest benefits of ERP is lost.
A Costing Problem I Have Seen in ERP Implementations
During ERP implementations, I have encountered a situation that illustrates the problem very well.
The business team asks:
“The purchase invoice is already posted. Why should we recalculate the cost?”
Let’s follow the transaction.
Purchase Order
1,000 KG @ ₹100
Goods Receipt
1,000 KG
Material Consumption
800 KG
Production
The 800 KG is consumed in manufacturing.
Finished Goods Receipt
400 units are produced.
Then the supplier invoice arrives:
1,000 KG @ ₹110
Now the additional ₹10/KG is not simply sitting against unused raw material.
800 KG has already been consumed.
That consumption has contributed to production cost.
Production has created finished goods.
Some finished goods may still be in stock.
Some may already have been sold.
Suddenly, one purchase price difference has created a chain of costing questions.
This is precisely why costing recalculation needs to be considered during ERP design rather than added later as a month-end workaround.
What Should a Good ERP Costing Engine Provide?
From an ERP implementation perspective, I would expect a good costing architecture to provide at least the following capabilities.
1. Cost Traceability
The user should be able to trace:
Finished Product → Production Order → Components → Inventory Transactions → Purchase → Supplier Invoice
The question should not be:
“Where did this number come from?”
The ERP should be able to answer it.
2. Cost Roll-Up
Where applicable, changes in lower-level component costs should flow into higher-level manufactured products.
For example:
RM → SFG → FG
The ERP should understand that relationship.
3. Controlled Recalculation
Users should be able to define the scope of recalculation.
For example:
- Product
- Warehouse
- Production order
- Period
- Organization
- Affected transaction chain
4. Recalculation Log
The ERP should maintain information such as:
- Recalculation date
- User
- Period
- Scope
- Original cost
- Recalculated cost
- Difference
- Reason
- Accounting impact
5. Accounting Integration
Cost adjustments should flow into the appropriate accounting treatment according to the configured costing method and accounting policy.
The costing engine and General Ledger should not operate as unrelated systems.
6. Audit Trail
A recalculation should not simply overwrite history.
The organization should be able to understand:
Original Cost → Adjustment → New Cost
This is essential for control and auditability.
7. Simulation or Preview
For significant costing adjustments, it is useful to know the expected impact before posting.
For example:
“This recalculation will affect 14 products, 6 production orders, ₹2.4 lakh of inventory and ₹1.1 lakh of COGS.”
That is far more useful than simply pressing a “Recalculate” button.
8. Exception Reporting
The ERP should help identify situations such as:
- Negative inventory
- Large cost variances
- Missing costs
- Production without complete component costing
- Significant invoice-versus-receipt differences
- Uncosted inventory
- Production orders with incomplete costs
- Unusual backdated transactions
Costing Recalculation Should Be Designed From Day One
One mistake I have seen in ERP projects is treating costing recalculation as something that can be added after the core ERP implementation is complete.
It should be considered during the original solution design.
Before implementing costing, the project team should define:
Costing Method
Will the organization use:
- Standard Cost?
- Moving Average?
- FIFO?
- Actual Cost?
- Periodic Average?
The appropriate method depends on the business, accounting requirements and inventory characteristics.
Cost Flow
The project team should understand the complete flow:
Purchase → Inventory → Consumption → WIP → SFG → FG → Sales
Cost Finalization
When is the cost considered final?
- At receipt?
- At invoice?
- At production completion?
- At month end?
- At period closing?
Recalculation Scope
Does recalculation apply to:
- One product?
- One warehouse?
- One production order?
- One period?
- All affected products?
Accounting Treatment
Where should the difference go?
Depending on the organization’s costing methodology and accounting policy, it may be treated through inventory, price variance, production variance, COGS or another appropriate account.
These decisions should be made during ERP design—not after the first costing problem appears.
Costing Recalculation Is Also a Management Tool
Costing recalculation is not only for accountants.
It can provide valuable information to management.
Suppose a product was planned at:
₹1,000 per unit
After actual costing, the ERP calculates:
₹1,125 per unit
The ₹125 difference deserves investigation.
Perhaps:
- Raw material prices increased.
- Labour efficiency decreased.
- Machine utilization was lower.
- Scrap increased.
- Freight increased.
- Supplier prices changed.
- Production volume was lower than planned.
- Actual activity costs were higher than expected.
The ERP is therefore not simply saying:
“The cost is ₹1,125.”
It is giving management an opportunity to ask:
“Why did the cost become ₹1,125?”
That question is much more valuable.
How Often Should Cost Recalculation Be Performed?
There is no single answer for every organization.
The frequency depends on:
- Business model
- Transaction volume
- Costing method
- Manufacturing complexity
- Accounting requirements
- Reporting requirements
Some organizations may need more frequent recalculation, while others may perform a more comprehensive costing process during month-end closing.
The important point is:
The frequency should be part of the ERP costing policy.
It should not depend on whether someone remembers to run an Excel calculation before the finance team closes the month.
The ERP Implementation Lesson
After working on ERP implementations across manufacturing, distribution, procurement, inventory, MRP, finance and costing, one lesson has become very clear to me:
ERP costing is not just a calculation. It is a chain of connected business transactions.
A supplier invoice can change raw material cost.
Raw material cost can change production cost.
Production cost can change finished goods valuation.
Finished goods valuation can change COGS.
COGS can change gross margin.
And gross margin can change management decisions.
That is the real importance of costing recalculation.
How Cyprus ERP and Onfinity ERP Fit Into This Picture
This is also why I believe costing should not be designed as an isolated ERP function.
In a manufacturing ERP such as Cyprus ERP or Onfinity ERP, the costing story needs to connect the operational processes that create the cost:
Procurement → Inventory → MRP → Production → WIP → Finished Goods → Sales → Finance
For manufacturing organizations, the costing architecture should be able to work with areas such as:
- Material purchase cost
- Purchase price differences
- Inventory transactions
- Material consumption
- Production orders
- Activity costs
- WIP
- Semi-finished products
- Finished goods
- Cost roll-up
- Inventory valuation
- COGS
- Period-end costing
The objective is not simply to produce a number called “Product Cost.”
The objective is to make sure that the number can be:
Explained.
Traced.
Recalculated.
Audited.
And most importantly, connected to the business transactions that created it.
A good ERP should allow a user to ask:
“Why is this product costing ₹X?”
And then trace that cost back through the production order, components, inventory transactions and procurement transactions.
That is what makes ERP costing useful in the real world.
Are Costing Differences Creating Problems in Your ERP?
If your organization is experiencing:
- Purchase price differences
- Incorrect inventory valuation
- Production cost differences
- Difficult month-end closing
- Unexplained COGS variances
- Backdated transaction problems
- Difficulty tracing product cost
- Heavy dependence on Excel for costing reconciliation
then the problem may not be a single accounting entry.
It may be a sign that the end-to-end ERP costing process needs to be reviewed.
Cyprus ERP and Onfinity ERP are built around connected ERP processes covering procurement, inventory, MRP, manufacturing, costing and finance.
If you are evaluating an ERP for a manufacturing or distribution business, costing should be one of the areas you examine carefully—not something to discuss only after implementation.
Explore Cyprus ERP
Explore Onfinity ERP
Request an ERP Demo
Final Thoughts
Costing recalculation may not be the most visible feature of an ERP system.
Users notice sales orders, purchase orders, dashboards, production screens, invoices and reports.
But behind those screens, costing determines whether the financial picture of the business can be trusted.
If inventory cost is wrong, inventory valuation can be wrong.
If production cost is wrong, product profitability can be wrong.
If COGS is wrong, gross margin can be wrong.
And if gross margin is wrong, management may make decisions using numbers that do not represent the actual economics of the business.
That is why costing recalculation should not be treated as a technical afterthought.
It should be designed as a fundamental part of the ERP architecture.
The strongest ERP systems are not simply systems that record what happened.
They are systems that can:
Understand the financial impact of what happened.
Trace that impact back to its source.
Recalculate the impact when new information becomes available.
And most importantly:
Give the business confidence that the cost shown by the ERP can be explained.
That is the real value of costing recalculation.
About the Author
Surya Sagar is an ERP Solution Architect and the founder of BRS Infotek, with more than 19+ years of experience in ERP consulting, solution design and implementation.
He has been involved in more than 100+ ERP implementations across different industries and has worked extensively with procurement, sales, inventory management, MRP, discrete manufacturing, financial management, costing and project management.
His experience comes not only from designing ERP functionality, but also from dealing with the practical problems organizations face during and after implementation—incorrect inventory valuation, production costing differences, late supplier invoices, backdated transactions, MRP issues, reconciliation problems and the gap between how a business process is expected to work and how it actually works on the shop floor.
Surya is also associated with the development and implementation of Cyprus ERP and Onfinity ERP, with a focus on building practical ERP solutions for manufacturing and distribution organizations.
His approach to ERP is simple:
An ERP system should not only record business transactions. It should help the business understand what those transactions really mean.
For more practical ERP insights, manufacturing scenarios, implementation experiences and ERP guidance, follow Surya Sagar’s articles and resources through ERP Pilot, Cyprus ERP and Onfinity ERP.
Cyprus ERP | Onfinity ERP | ERP Implementation | Manufacturing ERP | Inventory Costing | Product Costing | MRP | Cost Accounting
