Returns and claims calculator
It turns scattered business records into plain answers about money: what was lost, and what can still be recovered.
In most businesses, those facts are spread across files that nobody has time to join up, and a wrong figure costs real money. So the tool has one rule: be right, or say what is missing.
The first case
A small export business sells on Amazon and through other channels. The tool starts with its returns and refunds, recorded in platform reports, exports from its own order system, supplier contracts and quality agreements, chats with suppliers, and staff tracking sheets. The owner wants five answers:
How much money was lost?
How much can be recovered?
What are the risks right now?
Which things need my decision?
Who is handling what, and with what result?
Much of its other routine work could be lighter with automation too: the accounts could be easier to prepare before a person checks them, ad spend could be aimed more precisely, and its video editors and producers would have less to do.
What the tool does
It works through the records within a set scope, accounts for every file and every row, and answers the five questions on one page. Where the files cannot settle an answer, it says "unknown" and names what is missing instead of guessing.
Many businesses do not want to hand their records to a third party. So the data can stay inside the business: the tool is designed to run on a language model deployed on the business's own machines. Users who want a frontier model can use one instead.
I once interned at a state-owned company in China. There, company data never left the company, some office software ran only on approved hardware, and data was protected by level. That is where I learned how seriously a business can take its data.
Why I started
Machines can take over much of the mechanical work people do, so that people can spend their time on work that needs their judgement, or simply have more of it for themselves. I came to that view gradually, from many scattered things rather than one moment: years of using AI tools, handing more and more of my own work to AI agents, and what I read and heard about AI at work.
Tools that once took years to learn are getting easier too. People can now do alone what used to take a company. The more they rely on their tools, the more those tools have to be trusted, the way you trust a calculator never to get a sum wrong. I think the hard work belongs to whoever builds the product, so that what reaches the user is something reliable.
When I asked people who run export businesses how they work, I found that their workflows and their tools change all the time, and they stay loyal to none of them. They want a tool that is ready to use the moment they open it.
What "correct" means here
Do not get wrong what could have been found out.
Do not state as certain anything without evidence that holds up when checked.
Do not drop data.
Say "unknown" instead of guessing.
How it is built
A general engine, and modules that each know one kind of business problem. The first module handles returns and supplier claims.
Read (code). Every file gets a recorded outcome: read, or not read with the reason. The originals are never changed.
Recognise (code). Each table is recognised and every row is accounted for. Money is added up in code.
Ask (language model). A language model does the reading that needs context, such as matching a loosely described return to its supplier. Each question is narrow, and every call leaves through one gateway.
Check (code). Code checks each answer. Quoted evidence must exist in the files, numbers are recomputed, and certainty can go down, never up.
Decide (a person). Each answer becomes a card for a person, with no option preselected. Then one page: the answer, what is missing, one thing to do.
Ledger. Every step is recorded, so a run can be audited afterwards and resumed after an interruption.
What it will not do
Let the model add up money directly.
Fold an amount it cannot settle into the known total. That amount is listed on its own, with the reason.
Depend on a model to run at all. Without one, every question is recorded as unanswered.
What I did
AI agents write the code from task cards. I define what counts as correct and decide anything with real consequences.
Decisions from the work:
I checked the answer key before trusting the test. I went through the expected answers of a nine-case test set one by one. Of its 45 answers, 14 held up. 22 were wrong, 8 should have been "unknown", and 1 I could not settle. The answer key was then corrected. As I labelled more cases by hand and the fixes went in, the errors became fewer, and those left were mostly ones that need a long chain of reasoning, such as a judgement that can only be made by reading several files together.
I chose to read spreadsheet files directly, not as images. The number Excel showed on screen was not what an AI read from the same sheet. A displayed number can hide a formula, a raw value and a cached result. Later I let OCR back in, but only where it cannot mislead: for files where what you see is all the file holds, such as scans and screenshots, and as a second look at how a sheet is displayed, to flag where the display and the cells disagree. The numbers in a table are still read by code.
I ruled that money counts as recovered only when there is proof it came back. A record that says "paid" is not enough on its own; until the money is in, the case stays open.
I decided the tool has to read a business's own spreadsheets as they are, instead of asking the business to change how it works.
More on how I decide: How I work.
Where it stands
In progress.