Built by Avyth · self-initiated, not client work
Find inventory losses with no matching reimbursement, before the window closes
Amazon publishes inventory adjustments and reimbursements as separate reports. A seller who wants to know which losses were never reimbursed has to match them by hand — and each one has a filing window that quietly expires.
The real interface, with fictional demo data.
The approach
Both reports are read in the browser. Events are matched to reimbursements, unmatched events are surfaced as a worklist, and each row carries the time left to file: closing in 2 days, closing in 10 days, open, expired. The output is a list of things worth a human looking at, ordered by how soon they stop being actionable.
Decisions
And what each one cost.
Produce candidates, never claims
It would be easy — and dishonest — to total the unmatched events and call it money owed. Amazon decides what is eligible. The tool says where to look and how long is left; it never implies a payout.
Put the deadline on every row
A list of discrepancies sorted by value is the wrong tool: a large claim you can no longer file is worth nothing. Sorting by remaining window puts the reviewable work first.
Explain each match
Every row carries the reason it was flagged, so a seller can disagree with the tool. A reconciliation you cannot audit is one you cannot act on.
What it can't do
It reads the exports Amazon produced. It cannot see anything Amazon did not export, it does not file anything for you, and eligibility remains entirely Amazon's decision.
How it was checked
Run against sample adjustment and reimbursement exports containing matched events, unmatched events, and one already past its window — including the expired case, so the countdown is exercised in both directions.
Live flow last exercised .
Something like this, for your work?
If you have a job that looks like this one — mechanical, repetitive, and currently done by a person — describe it and I'll tell you whether it's worth building.