Pharma distribution has a second inventory nobody prices properly: the near-expiry stock crawling back up the channel. A chemist returns short-dated strips to the stockist, the stockist returns them to the distributor, the distributor files a claim with the principal — and then the money ages. The physical return took a week; the credit takes a quarter, because the claim is a photocopy bundle: debit note, batch details typed from the label, a covering letter, and a reconciliation argument at the other end about which return this credit was for. Meanwhile breakage claims travel a parallel paper road, and shortage-at-receipt claims a third. xMatix collapses the paperwork into one principle: the claim is built from the return and receipt documents that prove it, with the batch identity already attached — so the evidence is the transaction, not a bundle assembled after it.
The batch does the paperwork
Everything starts with the fact that xMatix stock is batch-tracked end to end: every receipt, sale and return line carries the batch, and the batch carries its expiry. So when short-dated or damaged stock comes back, the return is recorded against the batch it actually belongs to — no re-typing from the strip, no "batch as per annexure". The return posts as a credit document with its lines intact, and those lines are precisely what the claim will be made of: item, batch, quantity, value, the document that moved it. An expiry claim disputed six months later is answered by walking the claim line back to the return line and the batch — a lookup, not an investigation.
Returns become claims on a schedule, not on a reminder
The claims engine sweeps the return credit lines on the schedule the claim type declares — weekly, monthly, at period close — selects the lines that qualify (expiry claims and breakage claims are typically separate setups with their own rules), groups them by principal and branch, and writes one claim per group with the lines attached. The sweep is idempotent: each claim carries a generation key for its type, group and period, lines dedupe on their source, and the return lines a claim consumed are flagged in the same transaction. A re-run after a failed job creates nothing twice, and a return line cannot quietly end up on two claims. Nothing here is pharma-specific code — it is configuration over the documents the operation already writes, which is why a rate-difference or damage-in-transit claim joins the same machinery without a project.
Shortage is claimed at the gate, not discovered at month-end
The supplier-side claim that leaks the most is the one at goods receipt: the invoice says 200, the carton holds 196, and the difference dies in a margin note on the GRN. Here the shortage is captured on the receipt itself, line by line, and shortage claims are generated from those receipt lines — carrying the receipt, the item and the batch, addressed to the supplier the receipt names. Because the claim exists the day the truck was unloaded, the conversation with the principal happens while the despatch is still fresh on their side too — which is when it is cheapest to settle.
Settled in money or in stock
Approval works the way finance actually decides: line by line, with approved and rejected quantities and reasons, or approve-all when the claim reads clean — and partial approval settles partially, from the approved figures only. Settlement itself is configured per claim type. An expiry or breakage claim settles as a credit note linked back to the claim, posted into the same ledger the principal's account lives in. A shortage claim can settle as a part-to-part inventory adjustment instead — replacement stock rather than money, recorded as stock movement so the inventory position corrects itself the moment the claim settles. Either way the settlement document and the claim reference each other, which is what makes the year-end reconciliation with each principal a report rather than a negotiation.
Proven before it goes live
Claims configuration is payout configuration, so the engine assumes a trial period. New claim setups run in simulate mode: the full pipeline executes and reports the claims it would have written — principals, batches, amounts — without creating anything, and every setup save dry-runs its query against live data so a broken filter fails at save time. A distribution house migrating off the photocopy process runs one cycle in parallel, compares, and switches. The rollout pattern is the same one described in Simulate first.
The register the auditor asks for
Claims against principals are working capital wearing paperwork, and the questions a CFO or an auditor asks about them are all questions the ledger should answer: how much claim value is open against each principal, and how old is it; what was claimed versus what was approved, per period; which batches and which products generate the most expiry cost, and in which territories. Because every claim here is a document generated from documents — grouped by principal and branch, with approved and rejected figures per line and a settlement record linked back — those answers are reports over real records, not a year-end reconstruction. A multi-branch operation gets the same discipline per branch: claims group by the branch whose stock earned them, so a carrying-and- forwarding structure sees its claim position location by location, on the same operational spine the secondary sales flow already reports on. And the ageing itself changes behaviour: an expiry claim that exists the week the return posted gets chased; the one assembled at year-end gets written off.
Both sides of the counter
The same machinery serves the brand side of the channel. A pharma company receiving expiry claims from its stockists processes them on the same engine — generated or registered claims, line-level decisions, credit notes into the same ledger their schemes and collections already post to — and each stockist sees their own claims and status on the partner portal, scoped by record security to exactly their records. The claim that used to be a monthly grievance list becomes a shared statement both sides read from.
Common questions
How does an expiry return become a claim?
The return is recorded against the batch it belongs to and posts as a credit document with its lines intact. The claims engine sweeps qualifying return lines on the claim type's schedule, groups them by principal, and writes claims whose every line carries the item, batch, quantity and source document — so the claim is assembled from the transactions, not from photocopies.
What evidence does a claim line carry?
The source line it was generated from — return line or goods-receipt line — plus the item and batch identity that line already carried. A disputed line is answered by walking it back to the document and the batch, which also means a principal's query six months later is a lookup rather than a file hunt.
Can shortage claims settle as replacement stock instead of credit?
Yes. Settlement is configured per claim type: credit note, or a part-to-part inventory adjustment that settles the approved quantities in stock. The adjustment posts as a real inventory movement, so the stock position corrects at settlement rather than at the next count.
How do we introduce claim generation without risking wrong claims?
Run it in simulate mode first. A simulated run reports the claims it would have written — groups, lines, amounts — without creating anything, so finance can parallel-run a cycle against the existing process before activating. Once live, idempotent generation keys make re-runs safe: what already exists is skipped, never duplicated.