Expense categorizer
Write transactions the way you would say them. Each line gets an account, an amount and a confidence score. Everything runs in this page, no data is sent anywhere.
Describe a transaction
One transaction per line. The amount is the first number on the line.
Summary
Confidence tracks how many keywords matched. Below 0.5 the row is flagged, because a wrong account costs more time than an empty one.
Entries
| Description | Account | Amount | Confidence |
|---|
How this demo works
There is no model behind this page. A keyword table maps words like fuel, laptop or consulting to an account, and the score is a function of how many of those words matched. That is deliberate: it shows the shape of the output that automated categorization produces, and it makes the failure mode visible. Write a line with no recognizable word and you get an uncategorized row with a score of zero rather than a confident guess.
Production systems replace the keyword table with a model that reads the receipt image or the bank line, and they compare against your own history, so the second time you buy from the same supplier the account is already known. What does not change is the review step. Read what AI really does in accounting for where that line sits.
Reading the score
The number next to each row says how strongly the line matched, and nothing more. It is not a probability that the account is correct, and treating it as one is the mistake this demo is designed to make visible. A line reading fuel for the client's car scores high on the vehicle account and is still the wrong entry if the car belongs to the client and the cost is being rebilled.
The useful reading is the inverse: a low score means the system found little to go on, so look. A high score means it found familiar words, which is weaker evidence than it feels like.
Where matching on words breaks
- The same supplier, two purposes. A supermarket is office refreshments one week and a private shop the next. The line looks identical.
- Money moving the other way. A refund from a supplier is not revenue, and a payment to a subcontractor is not a customer transaction, though both read like the opposite at a glance.
- Names that are not words. Israeli bank lines are full of abbreviated business names with no descriptive content at all, which is why real systems match on your own history rather than on language.
- One line, two accounts. A hardware store receipt covering a repair and a tool is genuinely two entries, and no classifier splits it for you.
From a category to an actual entry
Choosing the account is the first of four decisions, and it is the easiest one. The entry is not complete until the amount is split between the deductible and non-deductible parts, the input VAT is either claimed or blocked, the document is attached, and the date lands in the right reporting period.
Those three remaining decisions are rules, not readings. The percentages come from regulation, which is why they belong in a maintained table rather than in a model's output. What each category is worth is set out in the deductible expenses guide, and the classic failures of the reading half are in what AI gets wrong on an Israeli receipt.
Nothing leaves this page
The classification runs in your browser. There is no request to a server, no account, and nothing stored between visits, which is also why the demo forgets everything when you reload. Paste real transaction lines if you want a realistic result; they do not go anywhere. A production system necessarily does send data somewhere, and that is precisely the point at which asking where it is processed, whether it trains a model, and how you get it back out stops being paranoia and becomes procurement.
Categorizing an expense is only half the job. Deductible percentages, input VAT and the record that survives an audit are the other half. Software that does this properly reads the receipt, fills the form, applies the percentages from a maintained table rather than from a model, and leaves the save to you.