An Amazon ASN chargeback happens when the notice you sent and the shipment that arrived stop agreeing — no notice for a line that arrived, counts that do not reconcile, a missing carrier reference, an absent expiry date. Late shipment charges share the cause: a purchase order window your system never treated as a constraint.
What the ASN is, and why its timing is the whole problem
The advance shipment notification is the virtual version of a physical shipment. It tells Amazon what is coming, in what quantity, against which purchase order, on which carrier reference. The fulfilment centre uses it to receive against. When the two disagree, the disagreement becomes a defect with a code and a cost, and the full chargeback reference lists what each one triggers on.
The word advance is doing more work than most teams notice. The notice has to be sent before the shipment arrives, and it has to describe what actually left the building. Those two requirements pull in opposite directions when a human types the notice: type it early and it describes a plan, type it accurately and it describes something that has already been received. Which is why the only reliable answer is for the notice to be produced by the event that creates the shipment — the pick — rather than by somebody at a keyboard afterwards.
That single change is the substance of this post. Everything below is a consequence of it.
The five ways an ASN goes wrong
Each of these has a defect code behind it, and each one is a record disagreeing with another record.
No notice arrived for a line that did
The shipment turned up and there was no ASN for that purchase order and item. Usually this is a process gap rather than a mistake: a shipment that went out through an exception route, a back-order filled later, a split delivery where only the first half was notified. The fix is that every outbound movement against an Amazon purchase order produces a notice by default, with no manual step that can be skipped under pressure.
The unit counts do not agree
There is a discrepancy between the units on the notice, the units received and the units on the purchase order. Three numbers that should be one number. This is where a hand-typed notice fails most often, because it is typed from the plan and the pick then differs by a case. It is also where over-picking shows up: ship more than the order asked for and you have created both a count mismatch and an overage defect from the same movement.
A carrier reference is missing or wrong
Depending on who is paying the freight, the notice needs the right carrier reference against the right appointment — a collect shipment and a prepaid one do not need the same one. This field is almost always correct in somebody’s inbox and absent from the notice, because it arrives after the notice was prepared. If the reference is captured on the delivery order when the booking is made, it is on the notice automatically; if it lives in an email, it will be missing some of the time.
An expiry date is absent where the catalogue requires one
Some products carry an expiry requirement in Amazon’s catalogue, and for those the date has to be on the notice. The date almost always exists — it is on the lot in your warehouse. The problem is that it has to travel from the lot, through the pick, onto the notice, without a human copying it. Re-keying is where it is lost, and the defect is charged for the absence rather than for anything being wrong with the stock.
The notice was right when it was sent and wrong when it shipped
The quietest failure of the five. Somebody notified the shipment, then the warehouse short-picked, substituted a lot or split the load, and nobody went back to the notice. Nothing in the process is obviously broken, so nothing gets investigated — the chargeback simply reappears next month. The guard is that a change to the delivery order after notification is treated as an event that must update or replace the notice, not as a quiet edit.
Getting the same defect code every month?
Send us a month of chargebacks and we will tell you which are a sequencing problem in your ERP, which are a master data problem, and which are genuinely happening on the floor.
Talk to Us About ChargebacksLate shipment is the same problem wearing a different code
On-time accuracy is charged when the ordered items did not arrive inside the ship or delivery window on the purchase order, and also when you did not send every unit you confirmed. Both of those start at the same moment: the acknowledgment.
Acknowledging a purchase order is a commitment, and in a lot of businesses it is made by somebody who cannot see whether the stock will be there or whether the window is achievable. The order gets confirmed in full because confirming in full feels like good service, and the shortfall surfaces three days later when the pick is short. By then the choice is between a late charge and a fill charge.
The ERP-side fix is unglamorous. The window dates on the purchase order should drive the scheduling dates on the delivery order directly, so the deadline is a property of the document rather than something in somebody’s head. Confirmation should be checked against real availability before it is sent. And the alert should fire before the window closes rather than after it, because an alert after the fact is a report, not a control.
Why this is a sequencing problem, not a warehouse one
Read the five failures again and the pattern is hard to miss. Late acknowledgments, counts that do not reconcile, expiry dates that never made it onto the notice, carrier references sitting in an inbox, availability you could not actually fill. None of those are solved by working harder in the warehouse. They are solved by the purchase order, the pick, the notice and the invoice being the same record instead of four records that have to be reconciled by hand.
That is the argument for integrating Vendor Central with the system that already holds the stock, rather than working in the portal alongside it. The Amazon Vendor Central connector for Odoo exists to do exactly that: receive the purchase order, acknowledge it inside the window, build the notice from the actual pick, carry lot and expiry through, and send the invoice electronically. If you are on the Seller Central side instead, the Amazon Odoo connector is the equivalent, and the integration guide covers how orders, stock and invoices move either way.
What to change first, in order
Make the notice a consequence of the pick. If one thing changes, make it this. The notice should be generated from the delivery order, carrying quantities and lot data as picked.
Put the purchase order windows on the delivery order. Ship and delivery windows become scheduling dates, with an alert before the window rather than a report afterwards.
Enforce the ordered quantity as a hard limit. A picker should not be able to exceed the ordered quantity, which removes the overage and the count mismatch in one change.
Capture the carrier reference where the booking happens. On the delivery order, at booking time, not in a reply-all.
Treat a post-notification change as an event. If the delivery order changes after the notice has gone, something has to update the notice. A silent edit is the most expensive kind.
Then measure by defect code, not by total. A single monthly figure tells you nothing actionable. The same code appearing every month is a process fault; a different code each month is usually noise.
What this will not fix
Preparation and packaging defects are physical. Bagging to specification, suffocation warnings, stickering, taping, opaque covering, cap seals, dunnage, carton weights and sizes — none of those are an ERP problem, and an integration that claims to prevent them is overselling. They are solved by documented, item-level prep instructions that reach the person doing the work, and by someone checking.
Nor will an integration recover money you have already been charged. Disputes are a separate exercise, they take evidence, and the evidence is only assemblable if your records agree — which is the same thing prevention gives you. If your records do not agree today, start there, because it serves both jobs.
And if your chargebacks are concentrated in preparation and packaging rather than in the purchase order and notice families, the honest answer is that your warehouse instructions need the attention and your ERP does not. We would rather say that than sell an integration that addresses the wrong half of your bill.
Being straight about our own position
We build the Amazon Vendor Central connector for Odoo and we do Odoo support and maintenance, so we have an interest in integration work existing. Weigh what we say accordingly and get a second view. We are not an Amazon partner and hold no Amazon certification.
What we would not do is quote before seeing a month of your actual chargebacks broken down by code. A supplier who quotes an integration without asking which defects you are actually paying for is guessing at the value, and the number will move once they find out.
Where to start
Export last month’s chargebacks and group them by defect code. If the purchase order and notice families dominate, the problem is sequencing and it is fixable in your system. If preparation and packaging dominate, put the effort on the floor instead. That half-day of sorting decides where the money should go, and it costs nothing.