An ERP migration plan is a serious document. Finance, inventory, procurement, order management, month-end close, the chart of accounts. Every one of those has an owner, a workstream, and a person whose job depends on it landing correctly.
Warranty claims usually have none of that.
Claims sit in the gap between customer service, finance, the warehouse and supply chain. Four teams touch them. None of them own them. So when the ERP project kicks off and every department names what it needs from the new system, warranty claims are the thing nobody puts their hand up for.
Then the ERP goes live, and the claims process is either broken or gone.
Why the claims process is always the orphan
Ask who owns warranty claims in a brand running 5,000 cases a year, and the answer is usually a shrug followed by a name.
Customer service handles the customer. Finance handles the credit note. The warehouse handles the physical product. Supply chain handles the supplier relationship. One person, somewhere, holds the whole thing together in their head and in a spreadsheet, and everybody else assumes it is handled.
That works until the ERP changes. Then the spreadsheet still exists, but half the things it referenced do not.
The pattern repeats across brands. The ERP decision is made on finance and inventory grounds, correctly. The integration scoping covers order flow and stock. Six weeks before go-live, somebody in customer service asks where warranty claims are supposed to go, and the answer is a silence followed by a workaround.
What actually breaks
1. The custom development does not come with you
Most ERPs that have been in place for a decade have been customised heavily. Claims are often part of that. A field added here, a report built there, a workflow somebody's predecessor coded in 2016 and documented nowhere.
None of it travels. The new ERP is a different system with a different data model, and the customisations are not portable. They get rebuilt, or they get dropped.
Claims customisations almost always get dropped, because rebuilding them competes for developer time against finance and inventory work that has a hard month-end deadline. Claims do not have a deadline. They just have a person who is about to have a much worse job.
This is also the moment a lot of brands notice the trap they were already in. The reason the ERP is being replaced is often that it was developed past the point of usefulness in the first place. Rebuilding the claims logic inside the new ERP starts the same clock again.
2. The claim loses its link to the product
This one is quiet and expensive.
When claims live inside the ERP, every claim is tied to a product record. That link is what makes defect analytics possible. It is how a brand knows that one SKU accounts for a third of claims, or that a specific supplier's components fail at three times the rate of everyone else's.
An ERP migration can sever that link. The product records get restructured, the claim records come across as history, and the relationship between them does not survive the mapping. The claims are still there. The ability to ask questions of them is not.
Brands have lost a full year of product-level claims analytics this way, and nobody notices until quality asks for a report and finds out it cannot be produced.
3. The claim to credit note chain snaps
This is the one that costs real money.
When a product fails because it was faulty from the factory, the cost belongs to the supplier. Getting that money back means submitting the claim with the exact documentation that supplier requires, tracking it, and chasing the credit note when it does not arrive.
That chain runs through the ERP. Break it during a migration and claims keep getting approved by suppliers while the credit notes quietly stop arriving. Suppliers are not being dishonest about it. They approve, they mean to issue the credit, and then nobody on either side is tracking it, so it never happens.
The loss does not show up as a line item. It shows up as margin that is slightly worse than it should be, for reasons nobody can point at.
4. Open cases have nowhere to live
An ecommerce cutover happens on a weekend. An ERP cutover is a season.
Through that whole period there are live cases. Claims waiting on supplier approval, repairs at a service centre, replacement parts on order, credit notes pending. They exist in a system that is being switched off, and the new one is not ready to receive them.
The default answer is a spreadsheet, held by one person, for the duration. That spreadsheet is where cases go to be forgotten.
5. The people who knew the workarounds are busy
The person who holds the claims process together is usually also the person the ERP project needs for testing, data validation and training. For the length of the migration, their attention is somewhere else.
An undocumented process with an absent owner is a process that is about to degrade, right at the moment volume from the migration itself is going up.
Your new ERP has a warranty module. Here is why teams still do not use it
Most modern ERPs ship something that handles returns or warranty in some form. On the vendor's feature list, the box is ticked. In the project plan, that looks like the problem is solved for free.
It is worth understanding what that module is actually for.
An ERP is a system of record for the business. It is built for finance, stock and transactions, and it is used by employees. A warranty claim starts outside the business, with a customer holding a broken product and a phone. It needs a customer-facing front door, evidence capture, rules that differ per supplier and per SKU, and a workflow that runs through repair, replacement, spare part or rejection before it ever becomes a transaction.
ERP warranty modules are built for the last part of that. They are the accounting end of a process whose hard parts all happen earlier.
The practical test is simple. Ask whether a customer will ever log into the new ERP to submit a photo of a broken chair leg. The answer is no, and everything that follows from that answer is the reason the module does not close the gap.
The timing problem, and why waiting is the wrong answer
ERP migrations are long. Six months is fast. Eighteen months is normal. Two years is not unusual for a group with multiple entities.
The instinct is to hold everything else until the ERP lands. Do not touch the claims process, do not add a system, wait until the dust settles and then look at it with a clear head.
Three things go wrong with that.
- The claims process degrades during the migration, not after it. The whole point of waiting is to avoid disruption, but the disruption is already happening, in the one process with no owner and no plan.
- The dust never settles. ERP go-live is followed by stabilisation, then by every project that was deferred during the ERP project. The queue does not empty.
- The integration work is happening right now. While the ERP project is live, connecting systems is a normal piece of work with a team and a budget. Afterwards it is a new request with neither.
The alternative is to decouple. A claims process that sits outside the ERP and connects to it does not need to wait for the ERP to be finished. It can go in before, run through the cutover, and reconnect to the new ERP on the other side. The claims process stays live while the system of record underneath it changes.
That is a different shape of project from the one most teams imagine, and a considerably smaller one.
What a claims process looks like when it sits beside the ERP
The shape that works keeps the ERP as the system of record and puts the operational process in front of it.
- A self-service portal where customers submit warranty claims, returns, repair requests and spare part requests, with photos, videos, serial numbers and order details captured before the case is ever created.
- Rules and workflows that decide what information is required per SKU, per supplier and per case type, then route the case to the right team.
- Supplier claims forwarded with the documentation each supplier demands, tracked until the credit note actually arrives.
- Analytics on which products fail, how often, and which suppliers are responsible, which is exactly the data an ERP migration tends to destroy.
- Claimlane's AI Agent, the first AI agent purpose-built for warranty claims and returns. It reviews the images and video the customer submitted, applies the warranty rules for that product and supplier, and recommends the resolution.
- Refunds, replacements and credit notes written back into the ERP, so finance keeps a single system of record and customer service never has to log into it.
Davidsen went from five agents handling claims to one or two. Black Diamond cut their warranty case SLA from 25 days to five.
If the ecommerce platform is moving at the same time, and it often is, the same argument applies there. Magento to Shopify migrations break aftersales in their own specific ways, and the two projects tend to arrive together.
Before the ERP plan is signed off
Ask two questions in the next steering meeting.
Who owns warranty claims in the new system. And what happens to a claim on a three year old product, submitted the week after cutover, from a customer who has never heard of the ERP.
If the room cannot answer both, the gap is real, and it is much cheaper to close now than in the stabilisation phase when everyone is already exhausted.
Book a meeting and we will map the claims workstream against your ERP timeline.
.webp)
