The trade spend leakage agent: managing accruals, deductions, claims, and retailer settlements

A major retailer pays a €4.8 million invoice. The payment received is €4.55 million. The retailer has deducted €250,000, and the remittance advice carries twelve deduction lines: promotional allowance, display support, pricing discrepancy, shortage, noncompliance fee, prior-period rebate, miscellaneous adjustment.

The deduction team starts investigating. One line relates to a promotion that ended six weeks ago. Another references a promotion number that does not exist in the manufacturer’s system. A third may be valid, but exceeds the available accrual. A fourth concerns a display agreement with no proof of performance attached. A fifth duplicates a claim already settled by credit memo. A sixth appears to belong to a different legal entity. A seventh combines three SKUs, two promotional events, and two financial periods into a single amount. The retailer has already taken the money.

The analyst searches the trade-promotion system, customer agreements, email attachments, retailer portals, invoices, sales volumes, proof-of-performance documents, accrual reports, prior claims, ledger postings, and receivables open items. The key account manager believes the claim is probably valid. Trade marketing remembers agreeing to the promotion but cannot find the signed terms. Finance sees a €180,000 accrual against a €215,000 claim. Sales argues the difference should be approved to protect the relationship. The analyst notices that €35,000 may relate to stores that never executed the display, and the debit note carries no store-level evidence. The claim is 61 days old, the account is on collections hold, and finance closes the quarter in five days.

Every remaining option is bad: approve without validation, reject and escalate a customer dispute, settle only the accrued amount, create another accrual, charge back the invalid portion, write off the difference, or carry the exposure into the next period. None of these is administrative. Each one moves revenue, margin, customer profitability, receivables, accrual balances, cash, the retailer relationship, audit evidence, and next year’s trade-spend decisions.

The commercial decision was made months earlier. The financial consequences only become visible now — and when the stages do not connect, value leaks.

Leakage never has one source. It arises because the original terms were ambiguous, the agreement was entered incorrectly, the wrong products or customers were included, the accrual rate was wrong, actual sales differed from the accrual basis, the retailer deducted before submitting evidence, the same activity was claimed twice, the proof was incomplete, the claim was matched to the wrong promotion, the organization approved it to avoid conflict, an invalid balance was written off, unused accruals were never released, settlements posted to the wrong accounts, or root causes were never corrected. The traditional process — retailer short-pays, AR creates a deduction, an analyst searches for documentation, sales provides context, finance checks the accrual, the claim is approved or written off — is reactive by construction. It begins after the cash has already been withheld and aims only at clearing the open item.

The objective is not to reject the maximum possible value of retailer claims, nor to clear deductions as fast as possible at any cost. It is to settle every legitimate obligation accurately and promptly while preventing unsupported, duplicated, miscalculated, misclassified, or avoidable expenditure from eroding net revenue.

Trade spend is the set of financial investments, discounts, allowances, rebates, incentives, fees, and commercial payments a manufacturer provides to channel partners: off-invoice discounts, bill-back allowances, scan-back rebates, volume and growth rebates, listing and distribution and display and feature fees, retailer media, loyalty funding, promotional price support, free goods, case allowances, performance incentives, logistics allowances, early-payment discounts, market-development funds, launch support, endcap fees, annual terms, and retrospective rebates. But not every retailer deduction is promotional — a short pay may equally concern a delivery shortage, damaged goods, a pricing error, freight, returns, tax, invoice duplication, compliance penalties, late delivery, unauthorized substitution, payment terms, or administrative fees. Misrouting those into the promotions queue is one of the most common and expensive process errors in the discipline.

Two distinctions do a lot of work. A trade promotion is a commercial event; trade spend is the financial investment supporting it — one two-week retailer event might carry a €0.20 per unit scan-back, a €25,000 display fee, €15,000 of retailer media, and a €5,000 catalogue feature, each with different eligibility, accrual rules, evidence requirements, settlement timing, accounting treatment, and approval authority. And a discount reduces the invoiced price immediately, whereas a rebate or allowance is earned and settled later — which is precisely why rebates generate claims, deductions, disputes, and accruals while invoice discounts generally do not.

Those eight numbers are the heart of the discipline, and organizations routinely treat them as one. Budget is spending capacity, not a liability. Commitment is an approved or expected obligation. Accrual is the amount the company currently estimates it owes based on eligible activity and approved calculation rules. Claim is what the customer requests; deduction is what the customer simply takes. Validation determines what portion the agreement, activity, proof, calculations, accrual, and policy actually support. Settlement is the authorized financial resolution — credit memo, on-account credit, payment, chargeback, debit memo, write-off, netting, or rejection. Reconciliation confirms agreement, accrual, claim, validation, settlement, receivables, ledger, and remaining exposure all agree. And closeout confirms no further claims are expected, valid claims are settled, excess accruals are released, underaccruals corrected, and the event is financially complete.

A claim-processing problem is usually created during agreement design. Ambiguous agreements create ambiguous claims; weak master data creates weak matching; poor accrual logic creates settlement variance. So a robust agreement has to define legal entities, the claiming account, the benefiting customer, retailer hierarchy, applicable products and hierarchy, stores or channels, dates, qualifying transactions, calculation basis, rates, tiers, caps, exclusions, required performance, proof requirements, claim period, settlement method, currency, taxes, approval, expiry, and dispute process.

The gap that matters most is between the commercial term and the system configuration. A signed term reading “customer receives 3% on qualifying sales above €2 million in the quarter” has to become executable logic: which legal entity, which product categories and exclusions, net or gross invoiced sales, threshold, rate, period, whether returns are deducted, whether credit notes are included, settlement method. A small configuration difference materially changes the liability — and it will not surface until the claim arrives. Compounding this, agreements exist at many granularities (customer group, retailer, banner, store, category, brand, SKU, period, promotion, spend type), planning often happens at aggregated levels while accruals and claims must operate at detailed account and product levels, and one transaction may qualify under several overlapping programmes — an annual rebate, a quarterly growth rebate, a promotional scan-back, a logistics allowance, a launch agreement. Whether those stack, exclude one another, calculate on gross or net, or follow a priority order must be explicit in the configuration, not inferred later during a dispute.

The mechanics determine everything downstream. Fixed-amount agreements (€50,000 for one endcap display in weeks 20–23) can accrue on approval, at activity start, on confirmed performance, or across the activity period — accounting policy decides, and the operational system must support the policy rather than invent one. Per-unit and percentage-of-sales rebates require the agreement to define the base precisely: gross or net invoiced value, excluding taxes, after returns, after discounts, after credit notes. Volume thresholds introduce the sharpest trap of all — a stepped calculation gives each tier its own rate, while a retroactive one applies the higher rate to the entire eligible base once the threshold is crossed, and the difference between the two can be enormous on the same signed sentence. Add rolling rebates over moving windows and growth rebates (which need a defined baseline period, comparable products, treatment of acquisitions, price effects, returns, discontinued SKUs, and currency), and the configuration surface is substantial.

Scan-backs fund against units scanned at checkout during a defined event, requiring POS data, eligible stores and SKUs, dates, promotional price, and units. Bill-backs invoice at regular price with the allowance claimed later. Fixed promotional fees — leaflet, display, endcap, online banner, retailer media — generally require evidence the service was delivered. Free goods settle in product rather than cash, which means tracking eligible quantities, the free-item order, inventory, tax, the reference agreement, and delivery. And prepayments reverse the usual order: the manufacturer pays first and the proof arrives later to validate and offset it.

Accrual design then has three dials that quietly determine accuracy: frequency (per invoice, daily, weekly, monthly, quarterly — often decoupled from settlement frequency), basis (sales order, delivery, invoice, paid invoice, POS sell-out, distributor depletion, verified performance), and inclusions (returns, cancellations, credit notes, free goods, settlement discounts, taxes). True-ups adjust the estimate as actual volume, revised forecasts, promotion completion, returns, received proof, validated claims, or agreement changes arrive; reversals release liability when an event is cancelled, performance fails, qualifying volume falls short, the claim period expires, or no further payment is expected.

The short-pay lifecycle runs: invoice issued → payment received → payment differs from amount due → deduction created → claim investigated → settlement approved → receivable and settlement documents applied. An invoice-related deduction short-pays a specific invoice; a non-invoice-related deduction withholds against the account balance without identifying one, which requires a claim investigation linked to the customer account. A manual claim arrives independently of any short payment — a retailer-media invoice, an endcap fee, a market-development claim, a retrospective rebate. And customers also overpay, so the process must distinguish true overpayment, unapplied cash, offsets against open claims, duplicate payments, and credit balances.

Two structural rules govern how claims are handled. Preserve the customer reason and the internal root cause separately: the retailer may code “promotion allowance” while the internal cause is “promotion was never configured in TPM” — and only the second one is actionable. And never approve the claim header: one debit note may contain many lines, each needing a different promotion, product, amount, evidence, resolution, and approver, and invalid lines hide comfortably inside a document whose total looks reasonable. A single line may itself require allocation across several promotions, spend types, products, or periods, and unresolved balances after partial settlement may need a child claim rather than a silent write-off. Track ageing throughout — days since deduction, days in current status, days waiting on the customer, days waiting internally, days since approval — because old claims create customer friction, collection holds, distorted receivables, stale evidence, close uncertainty, and rising write-off risk.

Proof of performance demonstrates the partner completed the activity required to earn the payment, and its requirements vary by spend type: a display fee wants dated store images, a store list, compliance percentage, and duration; a catalogue feature wants the copy, publication dates, circulation, and correct SKU and price; retail media wants the campaign report, impressions, placement, dates, audience, and agreed deliverables; a scan-back wants POS units, stores, dates, eligible products, and the price condition; a listing fee wants the product active, store distribution, listing date, and retailer confirmation. Classify evidence honestly as complete, sufficient with exception, incomplete, contradictory, or unverifiable — and remember that proof does not define entitlement on its own. A photograph of a display does not prove all stores executed, that the full event duration was served, that the amount is right, or that nothing was paid already.

Claim inputs are unstructured: PDF debit notes, spreadsheets, email attachments, scanned images, retailer-portal exports, EDI remittance data, invoices, photographs, performance reports. Ingestion runs receive → malware and file validation → classification → text and table extraction → header extraction → line extraction → customer and product normalization → claim linking → human review where required. Header fields cover retailer, claiming entity, debit-note number, invoice and payment references, date, currency, total, reason, promotion references; line fields cover line number, product, retailer SKU, GTIN, quantity, rate, amount, period, store, promotion, reason, tax, and reference. Table extraction is where the damage happens — wrapped lines, merged cells, negative values, thousands separators, decimal conventions, multiple currencies, handwritten notes, poor scans, and subtotal rows double-counted as line items. Store confidence separately for the header, each line, each field, the claim link, and the product match, and route high-value or low-confidence documents to review. Linking a debit note to the wrong receivable can be effectively permanent, which is exactly why ambiguous links need a human.

Matching is then four distinct problems, not one: document-to-receivable (which deduction or open item does this debit note belong to?), claim-to-agreement (which commercial agreement creates the potential entitlement?), claim-line-to-promotion (which promotion and spend type supports each amount?), and claim-to-accrual (which balance is available for settlement?). Candidate scoring combines customer match, date overlap, product overlap, spend-type compatibility, amount similarity, reference similarity, and accrual availability — producing fully matched, partially matched, or unmatched outcomes, with a single claim line often spreading across several promotions plus an unmatched remainder. Allocation across those promotions must be reproducible: driven by specific evidence, product-level sales, accrual proportions, store-level performance, or chronological order, and stated explicitly.

Duplicates deserve their own machinery, because they are pure leakage when missed and pure customer friction when falsely flagged. They arrive as the same debit-note ID, the same retailer invoice, the same promotion and amount, the same proof document, the same claim submitted through different channels, a prior credit memo, a prior deduction settlement, or split documents — as exact duplicates, as near duplicates with a different document number but substantially identical amount, customer, promotion, period, and proof, or as cross-entity duplicates where the customer claims the same activity from multiple manufacturer entities. And approved claims that are not yet settled must reserve their entitlement, so a second claim cannot consume the same accrual while the first is in flight.

Every claim line should pass a validation stack: identity (claiming entity, hierarchy, legal entity, payment recipient, settlement account, product, currency), agreement eligibility (valid agreement, effective dates, customer and product and spend type included, exclusions, cap, claim deadline), transaction eligibility (qualifying invoice, shipment, POS sale, unit, store, return, credit note), performance, amount (recalculated by deterministic services: eligible base × approved rate + fixed amount − exclusions), accrual, duplicate, accounting, tax, and authority. Line outcomes are correspondingly specific — fully valid, partially valid, invalid, duplicate, insufficient evidence, wrong entity, out of claim period, requires commercial exception, requires accounting review, requires tax review.

The output of that stack is a claimed-to-validated bridge: claimed amount minus ineligible products, ineligible dates, unsupported stores, duplicate portion, incorrect rate, and prior settlement, plus any approved true-up. Then settlement is a separate, controlled financial action — a valid claim does not settle itself. The method matters: a credit memo on invoice reduces a specific balance; an on-account credit memo creates unrestricted customer credit; cash or AP payment applies where the agreement requires it; a chargeback recovers a deduction the manufacturer rejects; a debit memo charges back an overpayment or invalid credit; a write-off closes a balance without recovery and demands policy and authority; netting offsets open credits and deductions where permitted. Partial settlement is the normal case: settle the validated €82,000, dispute or charge back the remaining €18,000. Small residuals may auto-write-off under policy; large or risky amounts must not.

Settlement also carries its own failure surface. Currency needs a defined exchange-rate date, source, rounding, and FX difference treatment when claim, agreement, invoice, and settlement currencies differ. Credit notes and invoices may require tax calculation and reporting. And critically, settlement execution is not settlement completion: an approved request can still fail on an ERP error, tax setup, a closed period, a customer block, an invalid account, a duplicate document, or an interface failure. Completion requires confirmation from the execution system — which is why the settlement package must carry claim, agreement, evidence, validation, approval, method, financial document, accounting posting, and remaining balance together.

Reconciliation runs across a cube of customer × promotion × spend type × product × period × currency × legal entity. At promotion level it compares planned, approved, accrued, claimed, validated, and settled spend against remaining accrual and expected future claims; the customer checkbook aggregates budget, commitments, accruals, claims, settlements, remaining balance, and disputed balance. Claim-to-ledger reconciliation confirms status, settlement document, posting date, account, amount, tax, receivable application, and residual; settlement-to-receivable reconciliation confirms the deduction is cleared or reduced, the invoice dispute updated, the credit memo applied, the receipt allocated, and no duplicate open item left behind. Period close then requires open claim review, aged deduction review, accrual recalculation, settlement reconciliation, overaccrual release, underaccrual true-up, unmatched cash review, write-off approval, and certification — with an explicit cut-off policy, since claims arriving after close routinely relate to earlier activity.

Three exposures deserve standing visibility. Incurred but not claimed: the retailer has earned entitlement but has not asked, so the accrual must reflect the estimated obligation under approved policy. Claimed but not accrued: which is either a valid underaccrual, an invalid claim, a timing difference, a wrong legal entity, or a missing agreement — and the distinction is the investigation. Accrued but never claimed: the retailer may not have submitted, may have deducted elsewhere, the event may not have qualified, the accrual may simply have been excessive, or the claim period may have expired.

The ten kinds of leakage

• Agreement leakage. Unsigned terms, ambiguous language, unauthorized side agreements, wrong rate, missing cap, overlapping programmes, expired agreements still in use.
• Master-data leakage. Wrong customer, hierarchy, product, GTIN, legal entity, currency, or effective dates.
• Accrual leakage. Over- and underaccrual, duplicate accrual, wrong basis or rate, failure to reverse, settlements that never reduce the accrual.
• Claim leakage. Duplicate, unsupported, out-of-period, wrong product or customer, overclaimed units, wrong calculation, invalid fee.
• Deduction leakage. Short pays accepted without evidence, misclassified deductions, deductions left unresolved, invalid deductions written off, duplicate credits applied.
• Proof leakage. Incomplete proof accepted, false or duplicated evidence, partial performance paid as full, wrong store coverage or event dates.
• Settlement leakage. Duplicate payment, wrong method, excess amount, wrong currency or tax, payment to the wrong entity, unapplied credit.
• Process leakage. Slow resolution, missing owner, repeated handoffs, email approvals, no reason code, no escalation, weak segregation of duties.
• Commercial-behaviour leakage. Approving invalid claims to protect the relationship, funding unplanned activity, side agreements, excessive exception use, retailers deducting before validation.
• Learning leakage. Root causes never recorded, retailer patterns never identified, recurring deductions never prevented, accrual models never recalibrated, agreement templates never improved.

Which is why clearing the deduction is not the objective. The root-cause hierarchy runs from customer behaviour through commercial agreement, promotion setup, price and invoice, order and delivery, claims process, accrual process, master data, system integration, and internal authorization — and the patterns are usually legible once anyone looks: Retailer A raises frequent unsupported display claims, Retailer B has a systematic price-file mismatch, Plant C generates shortage deductions after mixed pallets, Sales Team D has a high rate of unrecorded side agreements. Prevention then belongs to whoever owns the defective process — pricing, logistics, trade marketing, sales, master data, IT, or retailer operations — not to the deduction team that merely found it.

Customer payment, debit note, invoice, or claim
  -> document intake + receivables integration
  -> extraction and normalization
  -> Trade Spend Leakage Agent
  -> agreement, promotion, sales, accrual, proof,
     receivables, settlement, and accounting tools
  -> deterministic validation and calculations
  -> claim recommendation
  -> human approval or policy-bounded automation
  -> credit, payment, chargeback, write-off, or rejection
  -> receivables and ledger reconciliation
  -> root-cause prevention and learning

The agent interprets debit notes and evidence, classifies claim types, identifies missing information, searches candidate agreements, coordinates matching, compares claimed against validated amounts, diagnoses differences, prepares settlement recommendations, routes approvals, monitors execution, and identifies recurring leakage patterns. Deterministic software owns accrual, rate and tier calculations, tax, currency, duplicate checks, financial postings, receivable applications, authority checks, settlement execution, and reconciliation. Humans own commercial interpretation, accounting policy, tax decisions, exceptional settlements, customer negotiation, write-offs, material approvals, and accountability. Given the financial stakes, an independent evaluation layer before high-impact settlement is worth building early: it verifies correct customer, correct agreement, eligible dates, amount calculation, proof, duplication, accrual, accounting configuration, and authority.

The twenty-three stages

1. 01Receive the financial signal. Invoice short pay, account deduction, retailer invoice, debit note, manual claim, overpayment, accrual exception.
2. 02Create or link the claim case. Receivable open item, receipt, invoice, debit note, customer, legal entity.
3. 03Ingest supporting documents. Validate format, security, completeness, duplicate file, source.
4. 04Extract claim lines. Normalize product, customer, date, currency, amount, reason, reference, tax.
5. 05Classify the claim. Promotional, pricing, logistics, return, damage, compliance, nontrade, unidentified.
6. 06Generate agreement candidates. By customer, product, period, amount, reference, spend type.
7. 07Link to promotions and accruals. Exact matches, recommended matches, unmatched portions, ambiguous matches.
8. 08Retrieve proof of performance. Attachments, retailer portals, field-execution images, POS, campaign reports, prior correspondence.
9. 09Validate eligibility and performance. Through deterministic rules, not judgement.
10. 10Recalculate the amount. The valid entitlement, independently.
11. 11Check duplicates and prior settlements. Across all financial and claims records.
12. 12Check available accrual. Sufficient balance, underaccrual, overaccrual, reserved claims, wrong accrual.
13. 13Diagnose the variance. Claimed €100,000, validated €82,000 — and precisely which €10,000 is unsupported stores, which €5,000 is duplicate, which €3,000 is an incorrect rate.
14. 14Recommend resolution. Approve fully or partially, request evidence, reject, charge back, write off, escalate a commercial exception, or route to accounting review.
15. 15Route approval. By amount, claim type, exception, customer, legal entity, settlement method.
16. 16Reserve the approved amount. So no second claim consumes the same accrual.
17. 17Execute settlement. Authorized credit memo, payment, debit memo, chargeback, write-off, or netting.
18. 18Apply settlement. Clear or reduce the deduction, invoice dispute, open receivable, customer balance.
19. 19Update accrual and fund usage. Reduce, reverse, or true up the liability.
20. 20Verify posting. Settlement document, tax, ledger, receivables, currency, claim status.
21. 21Close or create a residual case. Handle the remaining balance explicitly.
22. 22Identify root cause. And assign a preventive owner.
23. 23Measure outcome and learn. Time, recovery, leakage prevented, customer response, recurrence.

• Intake and identity: get_receivable_open_item, ingest_claim_document (with security result), extract_debit_note (structured header and lines), resolve_customer_entity (claiming customer, rebate receiver, parent, banner, legal entity, sales area), resolve_product_entity (retailer SKU, GTIN, manufacturer SKU, hierarchy, unit conversion), classify_claim.
• Entitlement: get_customer_agreements (agreement, version, status, dates, products, customers, rules, settlement method), get_promotion_candidates (with match scores), get_spend_type_rules (eligibility, calculation basis, proof requirement, accounting profile, claim deadline), get_eligible_transactions (invoices, sales, shipments, POS, returns, credit notes).
• Accrual: calculate_accrual (deterministic), get_accrual_balance (accrued, reserved, settled, available, currency, last update), reserve_accrual (requires approved claim status), update_accrual_balance.
• Evidence: retrieve_proof_of_performance (approved sources only), validate_proof (activity, period, product, store coverage, completeness, confidence).
• Validation: calculate_claim_entitlement (a deterministic rules engine), detect_duplicate_claim (IDs, documents, amounts, evidence, prior settlements), allocate_claim_to_promotions, check_claim_deadline, check_accounting_profile — which applies policy and never creates it — calculate_tax_treatment (an authorized tax engine), generate_validation_bridge.
• Authority and decision: get_settlement_options (permissible methods for the claim class), get_approval_authority (approver, thresholds, segregation, escalation), create_claim_recommendation.
• Execution — the high-risk write tools: create_credit_memo_request, create_payment_request (with payment controls), create_chargeback, create_write_off_request (reason and authority required), settle_claim, apply_settlement_to_receivable, reconcile_claim_posting.
• Customer and prevention: create_customer_dispute_packet, create_root_cause_action, propose_trade_spend_learning — a reviewable candidate, never an automatic write.

Weak:   "This claim appears partially valid."

Strong: claim_id: CLM-48219   customer: Retailer A NL
        requested_amount:  EUR 250,000
        validated_amount:  EUR 198,400
        disputed_amount:   EUR  51,600
        variance_breakdown:
          EUR 22,000  duplicate claim
          EUR 18,600  unsupported display stores
          EUR 11,000  incorrect rebate rate
        available_accrual: EUR 185,000
        required_true_up:  EUR  13,400
        accounting_review: required
        duplicate_confidence: high   proof_confidence: medium
        approvers: Trade Finance Director, Key Account Director
        settlement_status: recommendation only

Three state machines run in parallel, and their granularity is the control. The claim moves through new, document required, extraction review, linked, classified, matching, partially matched, fully matched, investigating, waiting for customer, waiting for internal input, validation ready, pending approval, approved or rejected, settlement pending, settled or partially settled, chargeback, written off, closed, reopened. The accrual moves through planned, committed, accruing, reserved, partially settled, fully settled, true-up required, released, closed. The settlement moves through proposed, approved, submitted, posting, posted, application pending, applied, failed, reversed — and “applied” is the only state that means the customer’s balance is actually correct. Memory holds customer deduction patterns, recurring reason codes, retailer proof formats, agreement-matching mappings, payment behaviour, recurrent master-data errors, commercial-exception outcomes, validation performance, settlement failures, and root causes — never unsupported sales commentary, one-off retailer accusations, unverified claim rationale, low-confidence extractions, expired agreements, sensitive bank information, tax interpretations, or draft accounting conclusions.

Thirteen functions hold ownership here — trade finance (governance, accrual methodology, customer P&L, settlement controls, close), the claims analyst (investigation, documents, matching, evidence, recommendation), accounts receivable (cash application, deduction creation, customer balance, settlement application), the key account manager (relationship, commercial context, agreement interpretation, negotiation — but not unilateral settlement approval outside authority), trade marketing, RGM, customer service and logistics, controllership (accounting policy, ledger integrity, close, certification), tax, legal, internal audit, and data and IT. Above all of them sits the rule that makes the rest enforceable: material settlement must separate claim preparation, validation, approval, execution, and reconciliation. No single user — and no single agent — controls all five stages.

Auto-approval is legitimate and narrow. Low-risk claims may be eligible when they are fully matched, exactly calculated, backed by sufficient accrual and complete proof, free of duplicates and errors, below threshold, and settled through a permitted method. The governing principle: automate only where confidence is high, risk is low, the action is reversible, the policy is explicit, and evaluation is strong — and never measure auto-approval by volume alone, since a rising auto-approval rate with a rising false-approval rate is simply faster leakage.

A claim agent can fail by extracting the wrong amount, linking the wrong customer, matching the wrong promotion, missing a duplicate, using the wrong rate, accepting weak proof, recommending the wrong accounting, settling without authority, failing to clear the receivable, or leaving the accrual unreconciled — so evaluation follows the money. Document (classification, header and line extraction, amount, currency, product, reference accuracy), entity resolution (customer, legal entity, product, invoice, promotion), classification (reason, claim type, promotional versus not, invoice versus account deduction), matching (exact-match precision and recall, candidate ranking, full and partial match accuracy, false and missed matches), duplicate detection — where the two error types are asymmetric and both costly, since false duplicates delay valid payment while missed duplicates create direct leakage — proof (relevance, period, activity, store coverage, completeness, confidence calibration), financial validation (eligible base, rate, tiers, returns, taxes, validated amount, accrual allocation — tested deterministically), recommendation, control (correct approver, segregation, no approval bypass, no duplicate reservation, no overaccrual use, no unauthorized settlement), and settlement (correct document, amount, currency, tax, receivable application, ledger posting, accrual reduction, claim closure).

Trajectory tests require the agent to link the receivable, resolve the customer, retrieve the agreement, validate proof, recalculate the amount, check duplicates, check accrual, request approval, and verify settlement — while prohibiting approval from a customer email, silent payment above the validated amount, reuse of exhausted accrual, creation of accounting policy, bank-detail changes, and settlement without authorization. The KPI families then run operational (claim volume, deduction value, aged claim value, resolution time, touch time, backlog, first-pass resolution), matching (auto-link, auto-match, full and partial match, manual correction rates), financial (claimed, validated, rejected, recovered, written off, duplicate value prevented, overpayment prevented, accrual released, underaccrual identified, leakage prevented), accrual (accuracy, over- and underaccrual, unclaimed aged accrual, accrual-to-settlement variance, closeout timing), settlement (success, posting failure, unapplied credit, duplicate settlement, cycle time), root cause (claims by reason, customer and internal owner, recurring cause, preventable claims, recurrence after corrective action), customer (disputes, collections holds, unresolved balance, response time), and agent (grounded recommendation rate, unsupported claim rate, human override rate, false auto-approval, cost per claim).

The measure is net revenue and cash protected while valid customer obligations are settled accurately and promptly — not claims processed per day.

A household-care manufacturer and a national retailer. The retailer short-pays €250,000 across several invoices, with four claim lines: a €120,000 promotional scan-back referencing promotion P-482 at €0.20 per scanned unit, a €60,000 summer display fee, a €45,000 price discrepancy against invoice group 7281, and €25,000 of “miscellaneous” against a prior agreement. The agent links the shortfall to three invoices, retailer legal entity NL01, and deduction case CLM-48219; the debit-note number has not appeared before.

Scan-back. The agreement pays €0.20 per eligible scanned unit, 1–14 June, three specified SKUs, 500 participating stores. The retailer claims 600,000 units. POS evidence shows 575,000 eligible units — of which 15,000 were scanned outside the eligible dates and 10,000 relate to an excluded pack. Validated: 550,000 units × €0.20 = €110,000, against an available accrual of €108,000, requiring a €2,000 true-up.

Display fee. €120 per compliant store, maximum 500, for a two-week endcap with the approved assortment. The claim assumes 500 stores. Evidence covers 480 store records with sampled photographs: 440 compliant, 20 partially compliant, 20 with no valid evidence. Policy pays full for compliant, 50% for partial, nothing without evidence: (440 × €120) + (20 × €60) = €54,000, releasing €6,000 of the €60,000 accrual after settlement.

Price discrepancy. Of the €45,000, €30,000 relates to invoices issued one day after the new price became effective — the manufacturer’s billing was wrong— and €15,000 relates to invoices issued before the effective date, where the retailer’s claim is invalid. Validated: €30,000, with the root cause recorded as a customer price condition activated late in billing. Miscellaneous. No current agreement matches the reference, and the agent finds a prior claim for €25,000 — same customer, same activity, settled by credit memo three months earlier, with an identical proof document attached to the new debit note. Validated: €0.

The recommendation: approve €194,000 as a credit memo applied to the deduction, and dispute or charge back €56,000 — with a scan-back true-up of +€2,000 and a display accrual release of −€6,000. Approval routes to the Trade Finance Director and Key Account Director, with the Controller reviewing the true-up and the pricing team owning the billing root cause. The customer dispute packet carries line-level explanations, agreement references, eligible units, store-performance evidence, invoice dates, the prior-settlement reference, and the validated and disputed amounts — which is what makes the conversation with the retailer a discussion about evidence rather than a negotiation about goodwill.

Then the part that stops it recurring. Four root-cause actions follow: correct the excluded-pack mapping for scan-backs; require store-level proof before display claim submission; fix the effective-date integration between pricing and billing; and add proof-document fingerprinting across claims to catch the duplicate pattern automatically. Final outcome: €250,000 deducted, €194,000 of valid obligation settled, €56,000 of unsupported leakage prevented, €6,000 of excess accrual released, €2,000 of underaccrual corrected. The numbers are illustrative; a production workflow requires authorized accounting, tax, commercial, and financial controls.

1. 01Phases 0–2 — language, lifecycle, taxonomy. Agree what trade spend, commitment, accrual, provision, claim, deduction, validation, approval, settlement, write-off, and closeout each mean; map the current lifecycle end to end; standardize claim types, reason codes, root causes, settlement methods, and evidence standards.
2. 02Phase 3 — clean agreements and master data. Customer and product hierarchy, effective dates, rates, settlement receiver, promotion IDs.
3. 03Phase 4 — preserve full financial traceability. Agreement → accrual → claim → settlement → ledger, linked end to end. Without this, nothing downstream can be measured.
4. 04Phase 5 — deploy document extraction. Debit-note classification, header and line extraction, manual validation.
5. 05Phase 6 — add claim matching. Recommend receivable, agreement, promotion, and accrual; humans approve uncertain links.
6. 06Phase 7 — add deterministic validation. Eligibility, rate, tiers, dates, products, duplicates, accrual checks.
7. 07Phase 8 — add agentic investigation. Gather missing context, explain variance, prepare recommendations, route evidence requests.
8. 08Phase 9 — approval-based settlement. The agent creates authorized settlement requests; humans approve financial actions.
9. 09Phase 10 — closed-loop reconciliation. Verify claim, receivable, settlement, accrual, and ledger together.
10. 10Phases 11–12 — prevention, then touchless. Use patterns to reduce future deductions; only then consider policy-bounded automatic processing for exact-link, fully proven, low-value claims.

A strong pilot takes one market, one retailer, one claim family, one trade-spend mechanic, 500–5,000 historical claims, accessible agreements, reliable accruals, and engaged finance and AR owners — with scan-back claims, fixed display fees, promotional rebates, and invoice pricing deductions being the most tractable starting types. Avoid beginning with every customer, all claim types, unclear accounting policy, no agreement master, no historical settlement links, unrestricted automated payment, or poor receivables integration. Success criteria: cut claim-research time by 60%, raise accurate auto-match rate, detect duplicates reliably, reduce aged deduction value, improve accrual-to-settlement reconciliation, prevent unsupported settlements, and achieve zero unauthorized financial postings.

The minimum viable data is customer and product master, agreements, promotions, accruals, invoices, receipts, deductions, claims, settlements, credit memos, and reason codes; it strengthens with retailer POS, store execution, proof documents, delivery records, returns, EDI remittance, portal data, tax, accounting profiles, and workflow history. Three dimensions decide whether reconciliation is even possible. Identifiers: customer, legal entity, agreement, promotion, spend type, claim, debit note, invoice, receipt, settlement, product, GTIN. Time: agreement period, transaction, invoice, promotion, claim, receipt, settlement, posting date, and accounting period — eight dates that routinely disagree. Currency: agreement, claim, invoice, and settlement currency plus rate and rate date. And everything material —agreement, promotion, rate, proof requirement, accounting profile, approval policy — needs versioning, because a claim arriving today may be governed by terms that changed twice since the activity occurred.

1. 01Starting after the short pay. The upstream agreement and accrual problems remain untouched.
2. 02Treating all deductions as trade promotions. Pricing, logistics, damage, and compliance issues get misrouted.
3. 03Matching by amount alone. The wrong promotion is selected and the accrual is consumed.
4. 04Treating an accrual as proof of validity. The claim may still be duplicate or unsupported.
5. 05Treating insufficient accrual as proof of invalidity. The accrual may simply be wrong.
6. 06Approving the claim header. Invalid lines hide inside a plausible document total.
7. 07Ignoring proof coverage. Partial store execution is paid as full execution.
8. 08No duplicate search across settlements. Previously paid claims get paid again.
9. 09Letting sales approve everything. Customer pressure quietly overrides financial control.
10. 10Treating write-off as resolution. The balance clears; the leakage stays.
11. 11Accruals never released. Net revenue remains understated indefinitely.
12. 12Claims settled but deductions left open. Receivables never reconcile.
13. 13Credit memo created but not applied. The customer balance stays wrong.
14. 14One reason code for everything. Root-cause learning becomes impossible.
15. 15AI calculating settlement from prose. Financial control is lost at the arithmetic.
16. 16AI creating accounting policy. The system exceeds its authority.
17. 17Document text triggering actions. Prompt injection or fraudulent instructions bypass controls.
18. 18Auto-approval measured only by volume. False approvals become direct leakage at speed.
19. 19No commercial-exception transparency. Unsupported payments appear analytically valid.
20. 20No prevention loop. The organization processes the same deduction every quarter forever.

1. 01Resolve the transaction, customer, and claim identity. Claiming customer, legal entity, receivable, invoice, debit note, currency, product.
2. 02Establish the commercial entitlement. Agreement, promotion, spend type, eligible dates, calculation rules, proof requirements.
3. 03Connect evidence, activity, accrual, and prior settlements. Eligible sales, shipments, POS, proof, accrual, claims, credit memos, payments.
4. 04Obtain the independently validated amount. Eligibility, units, rates, tiers, performance, taxes, exclusions — recalculated, never accepted.
5. 05Verify duplicates, controls, and accounting. Duplicate, reserved accrual, authority, settlement method, accounting profile, tax, segregation.
6. 06Execute and reconcile the authorized settlement. Credit, payment, chargeback, write-off, application — then verify receivable, accrual, ledger, and claim.
7. 07Remove the root cause of future leakage. Agreement, process, data, retailer pattern, internal behaviour — with a preventive owner and a recurrence measure.

Part XXV in brief — the practitioner templates. The method ships as eleven working documents, and the set is unusually load-bearing here because each one is also an audit artifact: the agreement card (claiming entity, benefiting accounts, products, period, spend type, basis, rate, thresholds, cap, exclusions, proof required, claim deadline, settlement method, currency, accounting profile, approvers); the accrual card (eligible activity, calculated accrual, manual adjustment, reserved claims, settled, available, last true-up, closeout date); the claim intake card; the claim-line validation card (claimed versus eligible quantity and rate, proof status, duplicate status, available accrual, validated amount, variance reason, recommendation); the proof-of-performance card; the duplicate-review card (including proof fingerprint and similarity); the settlement card (validated amount, approved exception shown separately, total approved, method, document, tax, currency, approver, posting date, receivable application, accrual adjustment); the customer-dispute packet; the period-close card; the root-cause card (with frequency and a recurrence measure); and the trade-spend decision packet.

Is this the same as deduction automation?

No. Deduction automation classifies and routes short payments. The leakage agent manages the broader commercial-to-financial lifecycle from agreement and accrual through validation, settlement, reconciliation, and root-cause prevention.

Does an accrual prove that a claim is valid?

No. The claim must still pass eligibility, proof, calculation, duplication, and prior-settlement checks. And the reverse also holds: a claim exceeding the accrual may indicate an underaccrual, late data, or a misconfigured agreement rather than an invalid claim.

Should the language model calculate the validated amount?

No. Use deterministic calculation and accounting services. The model coordinates, investigates, and explains them — it does not do the arithmetic that determines what gets paid.

Can the agent determine whether trade spend reduces revenue or is an expense?

No. It should not create accounting policy. Qualified finance teams define and configure the treatment; the agent applies it, flags ambiguity, and routes review.

Can the agent issue a credit memo or approve claims automatically?

It may prepare or invoke a credit-memo workflow only within approved permissions and after required authorization. Low-risk, fully matched, fully supported claims below threshold may be eligible for automatic handling under explicit policy; material, unusual, incomplete, or high-risk claims should not be.

How does the agent detect duplicate claims?

By comparing identifiers, amounts, agreements, periods, evidence, products, prior settlements, and document fingerprints — across channels, periods, and where appropriate legal entities.

How are partial claims settled?

The valid portion is settled while the remainder is disputed, investigated, written off under authority, or carried as a residual claim. Partial settlement is the normal outcome, not an exception.

When should a claim be written off?

Only under explicit policy and authorized thresholds. A write-off clears a balance; it does not resolve leakage, and it should never substitute for investigating a preventable cause.

What should remain human?

Contract interpretation, accounting and tax policy, commercial exceptions, customer negotiation, material settlement approval, write-offs, and accountability.

What is the biggest AI mistake in trade claims?

Automating approval or settlement before establishing reliable agreements, deterministic calculations, duplicate controls, proof standards, accounting governance, and full reconciliation.

Trade spend is treated as a commercial planning subject. Deductions are treated as an accounts-receivable subject. Claims are administrative. Accruals are accounting. Settlements are transaction processing. These are not separate systems — they are stages of one financial lifecycle running from commercial promise through system agreement, qualifying activity, accrued obligation, retailer claim, evidence and validation, authorized settlement, receivables and ledger posting, to accrual closeout. When the stages disconnect, the organization pays the same claim twice, settles activity that never occurred, rejects valid customer claims, accrues too much or too little, carries old liabilities, writes off recoverable deductions, damages retailer relationships, misstates customer profitability, and repeats the same failure every quarter.

The Trade Spend Leakage Agent connects that lifecycle. It does not assume the retailer is wrong; it does not assume the retailer is right. It asks what was promised, who was eligible, what activity occurred, what evidence supports it, what amount was earned, what has already been accrued, what has already been paid, which portion should be settled, which portion should be disputed, which accounting and tax treatment applies, and which root cause should be corrected. It does not replace accounts receivable — it connects the deduction to the commercial entitlement. It does not replace trade finance — it supplies traceable evidence and calculations. It does not replace sales — it gives the key account team a defensible narrative. It does not replace controllership — it applies approved rules and exposes exceptions. And it does not replace the claims analyst — it removes the repeated searching, matching, and reconciliation that prevents the analyst from working on the ambiguous and material cases. The RECOVER Method walks the route: resolve, establish, connect, obtain, verify, execute, remove.

The defining question is not how to process retailer deductions faster. It is how to build a controlled commercial-to-cash system in which every valid obligation is settled correctly, every unsupported amount is challenged, every posting reconciles, and every recurring source of leakage is removed.