VAT IT success fees need a recovery-to-fee ledger

Define the recovery event before calculating the fee

VAT IT's current official page supports a narrow statement: it presents VAT reclaim across more than 60 countries on a success-fee basis. A finance or tax team still needs the contract to define what counts as success. Submission, authority acknowledgment, accepted eligibility, assessed refund, offset against another liability, issued credit, and cleared cash are not interchangeable events. The fee calculation should name the exact trigger and the evidence that establishes it. ^[1]

Create a settlement record for each claim population. Identify the legal entity, jurisdiction, period, invoice set, original currency, claimed amount, exclusions, submission identifier, authority correspondence, decision, approved amount, payment or credit reference, value date, bank or ledger evidence, and any later correction. Preserve rejected, reduced, carried-forward, offset, withdrawn, and duplicated amounts instead of forcing them into one recovered total.

Bind the provider invoice to the contractual fee basis

The commercial record should cite the executed agreement and effective schedule used for the charge. Record the covered service, fee percentage or other basis, recoveries included and excluded, minimums or caps where applicable, treatment of previously identified amounts, subcontracted work, taxes, expenses, exchange-rate source and date, rounding, invoice currency, billing entity, and approval authority. These are buyer-verification fields; the public VAT IT page does not state the reader's terms. ^[1]

Then reproduce the calculation from the authority outcome and cash evidence to the provider invoice line. A fee should not inherit an unsupported system label such as recovered. Reviewers need to see the eligible base, every adjustment, the applied contractual rule, the calculated amount, indirect-tax treatment on the service invoice, approver, invoice date, due date, payment, and reconciliation. A changed authority decision or returned payment should create a linked revision rather than overwrite the original calculation.

Reconcile claim, cash, fee, and accounting populations

Use separate populations for submitted claims, authority decisions, recoveries, provider invoices, payments, and accounting entries. Reconcile identifiers and amounts across them at a defined cutoff. Differences can arise from partial approvals, netting, interest, penalties, currency movement, bank charges, credit notes, reopened periods, claim transfers, payment batching, or one invoice covering several jurisdictions. Each difference needs an owner, reason, status, supporting evidence, and expected resolution date.

Test difficult cases before relying on the operating design: a duplicate invoice, an amount already claimed internally, a mixed-use expense, a refund paid to the wrong entity, a credit applied rather than cash received, a partial authority decision, a recovery reversed after the provider billed, a contract-rate change, two currencies, an invoice dispute, and a provider credit note. The test should expose whether tax, treasury, accounts payable, accounting, procurement, and the provider use the same recovery event and population.

Keep entitlement and commercial settlement separate

This decision is downstream of recovery eligibility. The existing Blue dot analysis governs whether a transaction-level opportunity can become a supportable claim and explicitly warns that an analytic output is not an entitlement. The present control begins after a claim population and outcome exist: it asks which recovered value activates a contractual fee, how the invoice was calculated, and whether cash, fee, net benefit, and journals reconcile. The two records should link without collapsing into one status.

VAT IT's page does not establish that any invoice is eligible, any claim was accepted, any cash was recovered, any fee became due, or any customer realized a net benefit. The defensible next step is to select one completed and one disputed recovery, reconstruct both chains from source invoices through authority outcome and provider settlement, and document every term or field that cannot be independently reproduced. ^[1]

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Indirect Tax Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.