Fiona
What it is
An internal tool that turns receipts and bank statements into a full set of financial statements in one upload.
Who it's for
Accountants at a services firm who used to build journals and ledgers by hand for every new client.
How it works
AI reads the documents, code does the accounting maths, and each run ends with one styled Excel workbook of seven sheets.
The problem
Context
An accounting services firm turned every new client's receipts and bank statements into journals, ledgers and a trial balance by hand. The work was repetitive, and every client needed the same seven sheets.
Client name withheld under NDA.
What we learned first
The firm didn't need an AI accountant. It needed the boring 80% (reading documents and classifying transactions) done reliably, so accountants could spend their time on judgement.
Constraints
- Six days to a usable MVP
- Serverless hosting with hard request timeouts
- AI that invents account names is worse than no AI
My role
Richard on this project
Project Manager & PRD owner
Product skills
- Requirements translation
- PRD writing
- AI vs code boundary
- MVP scoping
Project skills
- Sprint planning
- Jira
- Risk management
As product manager
- Translated the firm's accounting logic into a PRD engineers could build from
- Drew the line between AI reading and code calculating so every figure stays traceable
- Cut every feature that did not produce the report
As project manager
- Planned a 6-day MVP sprint and split the work across three engineers
- Ran the sprint board in Jira
- Listed risks and mitigations before the sprint started
Not my role
- Accounting sign-off stayed with the firm's accountants: human review is part of the flow
The work
Key decisions & trade-offs
- Decision 01
AI reads, code calculates
The model only extracts and classifies. Every number (ledger, trial balance, fixed assets, inventory) is computed by deterministic Python logic, and account names are force-matched to the client's chart of accounts.
Trade-off Less 'magic', far more trust. Accountants can trace every figure.
- Decision 02
Cut everything that didn't produce the report
No login, no database, service and trading companies only, opening balance assumed zero, max 15 receipts per run. One upload, one complete Excel file.
Trade-off Manufacturing and existing companies wait for a later version. The MVP shipped on time.
- Decision 03
Parallel build on mock data
The accounting-logic engineer built the ledger on a dummy journal while the AI engineer built the real journal, merged on day 4. Nobody waited on anybody.
Trade-off A risky merge day, so I planned a buffer day for type and balance errors.
How it was built
Upload receipts, bank statement and chart of accounts โ AI extraction โ journal โ ledger โ trial balance โ fixed assets โ inventory โ one styled Excel workbook, with a self-correction step that keeps debits and credits balanced.
- Serverless timeout โ cap the batch and tell users why
- AI hallucinated account names โ force-match to the chart of accounts
- Debits โ credits โ route the difference to a rounding account, flag for review
- Uploadโค15 receipts, bank statement, chart of accounts
- AI readsExtract & classify only
- JournalForce-matched account names
- Code calculatesLedger, trial balance, assets, inventory
- 7-sheet ExcelBalanced, ready for review
The result
- 6
- days from PRD to working MVP
- 7
- report sheets generated per run
- 30-60s
- processing target per run
What I'd do differently
I'd bring an accountant into the sprint review every day from day one. Most bugs turned out to be accounting assumptions.