Abacu

The problem

An accounting firm's month is mostly typing. Invoices arrive as PDFs, photos and email attachments in no fixed format, and somebody reads each one, pulls out the supplier, date, amounts and VAT, decides which account in the chart it belongs to, and types it into the ledger. It is the least interesting work in the building and it is where the errors come from.

The obvious fix, "let a model read the invoice", solves the easy half. Extraction is close to solved. Classification is not: which of the firm's accounts a given supplier's invoice belongs to is a judgement that differs between clients and lives in the head of whoever has been doing it for years.

What I built

Abacu is the intake half of an accounting-firm platform, in Hebrew, for Israeli firms. An invoice comes in, Gemini extracts the fields under a structured-output schema, and the system proposes an account.

What happens next depends on how sure it is. A high-confidence invoice from a supplier the firm has already seen is auto-approved and goes straight through. Anything else lands in a review queue with the extraction shown next to the document, so a bookkeeper is confirming rather than typing.

The loop that matters

The corrections are the product. When a bookkeeper moves an invoice to a different account, that is recorded as a supplier-to-account mapping for that client, not as a one-off edit. The next invoice from that supplier arrives already correct and skips the queue. The system starts general and becomes specific to each firm's chart of accounts through use, which means the tedious first month is what buys the quiet second one.

Export sits behind a pluggable adapter, because every Israeli firm runs a different accounting package and none of them are going to change it for a new tool. The domain logic lives in a shared package away from both the API and the web app, so the same rules run in the queue, in the export and in the tests.