Handle restitution: what to automate, what to keep human, and the data it needs

Software can already handle most of the matching, rate lookup and deadline tracking in restitution. People still own classification judgements, decisions about fixing rates in advance, and anything involving a disputed or rejected claim. None of it works unless product, licence and shipment records link cleanly to each other.

What restitution involves in practice

Restitution means claiming a refund, set by an authority, on exports of eligible goods. Most of these are agricultural products or goods processed from them. The refund depends on what the product is, what it contains, where it goes, and which licence or advance fixing certificate covers it. The claim only pays out once the exporter proves the goods left and, for some destinations, that they arrived. A security lodged against the licence comes back only when the export obligation has been met.

The work is part customs, part treasury and part record keeping. That mix is why it tends to be run by a small team that knows the exceptions by heart.

Steps software can take over now

Rate determination. Once a product carries the correct refund nomenclature code, a system can look up the applicable rate by destination and date. It can also apply any rate fixed in advance on the licence. Doing this by hand from published tables is slow and error prone.

Recipe calculations for processed goods. Where the refund depends on agricultural content, the calculation from a bill of materials is pure arithmetic. A system does it consistently, provided the recipe is the one declared to the authority.

Licence drawdown. Every export eats into the licence quantity. Tracking remaining balances, tolerances and expiry is exactly the kind of bookkeeping that rules engines do well. Alerts before a licence runs out or lapses prevent shipments going without cover.

Proof matching. Exit confirmations, arrival documents and transport papers arrive in batches and in different formats. Document extraction tools, including AI models, can read them and propose a match to the right export declaration. A person should confirm low confidence matches, though the bulk can flow through.

Deadline monitoring. Claims and proofs have filing windows. A system that flags open items approaching their limit is worth more than any amount of manual diary keeping.

Steps that still need a person

Classification is the obvious one. An AI tool can suggest a refund code from a product description, and that saves research time. But a wrong code can mean repaying refunds with penalties years later, so a qualified person signs it off and keeps the reasoning on file.

Whether to fix a rate in advance is a commercial call. It weighs expected rate movements against the cost of tying up a security. Treasury and sales usually need to be in that conversation.

Rejected or reduced claims need someone who can read the authority's reasoning, decide whether to contest, and gather evidence. Force majeure cases, lost documents and goods diverted to a different destination fall in the same category. So does any audit or recovery demand. These are negotiations, and the exporter is legally responsible for what gets submitted.

What has to be true about the data first

The product master must hold refund codes that have been checked, not inherited from an old spreadsheet. Recipes used for the refund calculation must match what production actually makes and what was declared. If a formulation changes and nobody updates the declared recipe, automation will simply repeat the error faster.

Each export shipment needs a hard link to the licence it draws on and the security behind it. Many teams hold these in separate places: the licence register in one file, securities in the bank or treasury system, shipments in the ERP. Until those are joined by a shared reference, no tool can reconcile them reliably.

Destination data has to reflect where goods really go, not just the first port. Document images and their metadata need to be retained in a form an auditor can retrieve. And there should be a clean history of rates applied, since recoveries often reach back a long way.

Questions to ask the people who run it

The documented procedure rarely shows the workarounds. These questions tend to surface them:

• Which products do you reclassify or check by hand every time, and why?
• Where do you keep track of licence balances when the system figure looks wrong?
• How do you find out a recipe has changed?
• Which proofs arrive late or never, and what do you do then?
• Has a claim ever been paid and later recovered? What caused it?
• Who decides on advance fixing, and is that written down anywhere?
• What do you check before releasing a security request?
• Which spreadsheets would stop the process if they disappeared?

The answers usually point to the data gaps more precisely than any system review.

Where changes tend to go wrong

Automating the claim submission before fixing the product and licence data is the common mistake. Claims go out faster, and so do errors. Another is removing the specialist from the loop entirely once matching works. Volumes look fine until a rule changes or an authority queries a batch, and nobody left on the team can explain how the original figures were built.

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.