Handle restitution: when claims rest on outdated product data

A frequent failure in restitution handling is a claim built on product data that no longer matches the goods shipped. It usually begins with a quiet recipe or classification change, surfaces when the paying agency queries a claim, and is fixed by linking product changes to claims.

How it starts

Restitution claims depend on a chain of reference data. Each exported product carries a refund code, a description of its composition and, for processed goods, the quantities of qualifying ingredients it contains. Licences and advance fixing certificates are drawn down against those codes. The claim amount is calculated from all of it.

The trouble begins outside the trade team. Production adjusts a recipe to use a cheaper sugar source. Procurement switches a dairy supplier whose powder has a different fat content. Marketing renames a product line and a new material number is created by copying the old one. None of these people think of restitution when they make the change. Why would they?

The material master gets updated for manufacturing and costing. The restitution attributes stay where they were. From that point on, every export declaration states one thing and the goods physically contain another. The system keeps producing claims that look complete and pass internal checks, because the checks only confirm that fields are filled in.

Sometimes the change runs the other way. A product is reclassified correctly in the customs tariff, but the refund nomenclature code attached to the licence is left untouched. The licence balance then drifts away from what is really leaving the warehouse.

How it gets spotted

Rarely by the team itself, at first. The usual trigger is external. A customs officer draws a sample at export and the laboratory result disagrees with the declared composition. Or the paying agency pays less than claimed and sends a notice that nobody downstream reads carefully.

Inside the business, there are earlier warnings for anyone who looks:

• Receivables for restitution that never clear, or clear at odd partial amounts.
• Licence balances that no longer reconcile with shipped quantities.
• Quality or lab certificates in the export file that quote figures different from the declaration.
• Short-paid claims written off as "agency adjustments" without anyone asking why.

The finance side often sees the problem first, as a stubborn open item. The trade side sees it last, once a formal recovery demand arrives and penalties are attached. By then the issue usually covers a long run of past shipments, not one.

How it is fixed

The immediate job is containment. Stop submitting new claims for the affected products until the correct composition and refund code are confirmed. Pull the recipe history from production and match it against declaration dates, so the exposure can be sized honestly.

Next comes disclosure. Agencies treat a voluntary correction far more kindly than a discovered one. Prepare corrected claims, repay what was overclaimed, and keep the working papers. Expect the agency to ask how the error happened and what has changed since.

The lasting repair is structural. Restitution attributes need an owner, and changes to recipes, suppliers or material numbers need to route through that owner before they go live. In practice this means adding the trade compliance role to the change approval workflow in the product master. A copied material should not inherit refund data automatically; it should arrive blank and force a decision.

Reconciliation also has to become routine. Someone in finance should compare claimed amounts with amounts received, and every short payment should be explained before it is written off. Licence balances deserve the same treatment against actual exports.

Finally, the documentation in the export file should be checked against the declaration before submission, not after. A lab certificate that contradicts the claim is evidence the business handed to the authorities itself.

Questions to ask the people who run it

The documented procedure usually describes a clean flow. The desk reality tends to involve workarounds, so ask directly:

• When a recipe changes, who tells the restitution team, and how do they find out if nobody does?
• How are new material numbers created? Copied from an existing one, or built fresh?
• What happens to a short payment from the agency? Who decides it is acceptable?
• Where do composition figures on the declaration actually come from: the system, a spreadsheet, or memory?
• Has a claim ever been corrected after submission? What prompted it?
• Who reconciles licence balances, and when was it last done properly?
• If a customs sample fails, who receives the result?

Listen for answers that name a person in place of a system. That person is often the only control holding the process together, and the failure tends to start the week they go on leave.

What brings it back

This failure returns after reorganisations, system migrations and supplier changes. Each one breaks the informal link between the people who alter products and the people who claim on them. Any change programme touching master data or product governance should treat restitution attributes as a named dependency, tested before cutover and owned after it.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.