Custom app · 2026
A1Flow: invoices to accounts
Employment, tax and accounting firm. Out of respect for the firm's and its clients' privacy, no real screenshots of the application are shown.
Turns invoice PDFs and photos into VAT ledgers, journal entries and exports ready to import into CONTASOL and Contasimple. An LLM extracts the data; accounting rules decide whether to trust it.
- React
- TypeScript
- Fastify
- Document AI
- Gemini
- ExcelJS
The problem
Every quarter, the firm typed hundreds of its clients' invoices into the accounting software by hand. Four things made it hard to automate.
Hours of repetitive typing
Date, number, tax ID, bases, VAT rates, withholdings… one invoice at a time.
Messy documents
Scans, phone photos, PDFs with several invoices inside, credit notes, disbursements, reverse charge, foreign tax IDs.
Strict import formats
CONTASOL and Contasimple only accept Excel files with exact columns, codes and numbering. One mistake and the import fails or the books don't balance.
Companies and sole traders differ
Sole traders keep different books, and you need to know whether an expense is deductible for their line of business.
The process
- Phase 1
Understand the firm
Sitting with the team to follow an invoice from start to finish, and what CONTASOL expects in every column.
- Phase 2
Extraction pipeline
Split, read, extract with an LLM and validate with accounting rules.
- Phase 3
Human review
Those that don't balance wait in 'Review required' and get fixed with the PDF alongside. The rest go straight through.
- Phase 4
Accounting exporters
VAT ledgers, third parties, a double-entry journal and sole-trader records, built from the official templates.
- Phase 5
Production
The firm's Windows server with Caddy and automatic HTTPS, in use from the first month and iterated weekly.
From PDF to spreadsheet row
Staff upload the PDFs or photos of each client's invoices. The application splits them, reads them, extracts the tax data, registers customers and suppliers, and produces the Excel files the accounting software imports directly.
What makes it reliable isn't the language model but what comes after it: if the amounts don't add up, the invoice isn't accepted.
- 01PDF or photo uploadedqueued, for bulk uploads
- 02Splittingone invoice per document, even when they arrive together
- 03Reading
The PDF's text layer
Digital invoices: around 70%, with no paid OCR
Document AI (OCR)
Scans and photos
- 04LLM extractioninto structured JSON
- 05Accounting validationbase + VAT − withholding = total · tax ID · total present in the text
Doesn't balance
Reprocessed with OCR and, if it still doesn't balance, sent to review
Balances
Customer or supplier registered automatically, with duplicate detection
- 06Excel for CONTASOL or Contasimple
The model
No database: all state lives in JSON files with atomic writes and per-resource locks. For a single server in the office it's enough, and it's trivial to back up.
The firm's staff sign in, with administrator and developer profiles, and so do its clients, who can only read their own invoices.
The rules that make it hard
Reading a simple invoice is easy. These are the ones that aren't, and each changes what gets written in the ledger and the journal.
Several VAT rates
A single invoice produces several ledger lines and several journal entries.
Credit notes and refunds
Negative amounts, a reference to the original invoice and their own treatment in the journal.
Withholding, disbursements, reverse charge
Each one changes which accounts are used and how the total balances.
Linked numbering
The entry code in the journal must match the record in the VAT ledger, or CONTASOL won't link them.
Non-deductible expenses
Depending on the company's or sole trader's activity, expenses unrelated to the business are flagged.
Statuses with accents
'Revisión requerida' versus 'revision': a silent bug that kept a button disabled for months, until diacritics were normalised in every comparison.
The project in numbers
- 8accounting export formats
- 2accounting packages
- 70 %of invoices read without paid OCR
- 70automated tests
- 30.000lines across 87 files and 43 commits
- 4months, in production from the first
What I took away
Measure before optimising
Before changing the OCR, a script compared the approaches on real invoices: on digital ones, the PDF's text got 85.9% right against 84.6% for OCR. The cheap option was also the best one.
The LLM proposes, the rules decide
The model extracts; validating amounts and tax IDs decides whether the invoice is trustworthy or goes to review.
The import format is the contract
Every exporter is tested against the official templates, because an almost-correct spreadsheet is useless.
Authorisation always on the server
Plus short-lived signed URLs for viewing the invoice PDFs.
And in your case?
Is your office still typing invoices in by hand?
Or your accounting software needs a specific import format nobody produces for you. I take freelance projects alongside my job, and if you tell me about yours I'll say plainly whether I can help.
Tell me about it →