How restitution is set up in finance and ERP systems

Restitution is usually run in a global trade module that sits beside the ERP. It links export declarations, licences and lodged securities to a claim against the customs or agricultural authority. Finance then books the expected refund as a receivable and clears it when the authority pays.

What restitution covers in practice

The word gets used loosely. In some businesses it means export refunds paid on regulated goods, typically agricultural products leaving a customs union. In others it means recovering duty already paid, through drawback schemes or corrections of overpayments. System design differs between the two, so the first job is to establish which one is in scope.

Export refunds tend to involve licences and securities. Duty recovery tends to involve matching import entries to later exports or to errors found in audit. Many companies handle both, often in separate places without anyone having decided that deliberately.

Master data that carries the weight

Most restitution problems trace back to product data. Each material needs a classification that the refund regime recognises. That code is often more granular than the ordinary tariff number. It may also depend on composition, such as sugar or milk content, held as an attribute on the material or captured per batch.

Refund rates are published by the authority and change. A trade module normally stores them in a table keyed by product code and destination, since some refunds vary by country of arrival and certain destinations are excluded entirely. Someone has to maintain that table, and it is worth knowing who does it and how quickly updates reach it.

Licences and securities

Where licences are required, the trade system records each one with its quantity, validity and the product codes it covers. Every export draws down against a licence. When the balance is gone or the validity lapses, the shipment should be blocked or flagged.

Securities are guarantees lodged with the authority before the export happens, often as bank guarantees or cash deposits. The system tracks each one against the licence or advance payment it backs. Finance shows them as contingent items or as deposits on the balance sheet, depending on how they were lodged.

Release depends on proving the export happened as declared. If that proof is late or incomplete, part of the guarantee can be forfeited. The loss lands in the ledger and is usually what a controller notices first.

From shipment to claim

The sales order and delivery in the ERP trigger the export declaration. The trade module copies restitution data onto the declaration so the authority can see that a refund will be claimed.

After the goods leave, evidence accumulates. Exit confirmations come back from customs electronically. Some products also need proof of arrival at destination, which often turns up on paper from a forwarder or the buyer. The claim file is assembled from these documents and submitted.

Teams frequently keep a claim status in the trade system: open, submitted, queried, paid or rejected. Good setups tie each state to a reminder so evidence chasing starts before the authority's deadline.

Accounting entries

Practice varies on when to recognise the refund. Some companies accrue it at the point of export, using the rate in force. Others wait until the claim is submitted, or until it is paid, because the outcome is uncertain. Whatever the choice, it should be agreed with the auditors and applied consistently.

Under accrual, the entry is typically a receivable from the authority against a reduction in cost of sales or a separate income line. Payment clears the receivable. Gaps between the accrued figure and the cash received go to a variance account that someone should review.

Forfeited securities and rejected claims need their own accounts. Mixing them with ordinary variances hides the operational failure behind them.

Reconciliation between the trade module and the ledger is often manual. One side knows the claims and the other knows the money. A periodic match by claim reference is the minimum control.

Where the documented process and the real one drift apart

Process documents usually describe a clean flow from order to payment. Daily reality includes spreadsheets tracking proof of arrival, a forwarder who emails scans to one person's inbox, and rates checked by hand before large shipments. None of that appears in the system design, yet the claims depend on it.

The drift shows up in accounting as well. A written accrual policy may sit alongside a habit of booking nothing until cash arrives, because the receivable was too hard to reconcile.

Questions to ask the people who run it

• Which regimes does the business actually claim under, and are any handled outside the trade system?
• Who updates refund rates and product classifications, and how do they hear about changes?
• When a licence runs short, what really happens to the shipment?
• Where does proof of arrival come from, and who chases it when it is missing?
• Have securities ever been forfeited, and what caused it each time?
• At what point does finance book the refund, and does that match the written policy?
• How are claim references carried into the ledger so payments can be matched?
• What gets tracked in spreadsheets that the system was supposed to track?
• When the authority queries a claim, who answers and where is the correspondence kept?
• Which steps would stop working if one particular person left?

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.