OttoMoney
The receipt ledger, two currencies side by side, and why Otto refuses to invent an exchange rate.
Live.
You earn and spend across Italy and Brazil. Most tools assume one currency and one country, so the ledger is built around having two of each.
The receipt ledger
One record per transaction, extracted from the receipts, order confirmations, invoices and card alerts the hourly scan already reads: merchant, amount, currency, date, category, and the id of the message it came from.
Without it, Otto re-reads the same mail forever and can never answer "how much did I spend on that" or "did the refund land".
Amount parsing is separator-aware, because 1.234,56 and 1,234.56 are the same
number written by two countries, and getting that wrong by a factor of a thousand
is the kind of bug that survives a long time before anybody notices.
Two currencies, never merged
Totals are reported per currency: by month, by category, by merchant. EUR and BRL sit side by side rather than being silently added together.
Conversion exists but takes the rate as an argument. Otto does not hardcode a rate and does not guess one, and when it cannot convert something it names what it could not convert rather than dropping it from the total. A total that quietly used last month's rate is worse than a total that admits it is two numbers.
Not built yet
These do not exist. The substrate each one reads is live, so every item below is a self-contained piece of work rather than a rewrite. The button copies a prompt that builds it in your own checkout.
One brief line: the next 7 days of committed outflows, month-to-date spend in BRL and EUR against the trailing 3-month average, and receivables outstanding; they get the money picture attached to every trigger and Otto stops making "is that a lot?" judgements blind.
A receipt for a watchable product auto-arms a price watch for the length of that retailer's price-protection window, and a drop produces one message with the delta and a pre-drafted claim ready to send on a tap; they never sets it up, it expires itself, and it ends in money back rather than a notification.
Every purchase confirmation records return-by (14 days EU, 7 days CDC online) and warranty end (24 months EU, 90 days CDC) with the receipt attached, a brief line for windows closing this week, a T-3 "keeping the X?" whose [return it] drives the merchant's return flow and produces the label, and "is this still under warranty" answerable a year later; warranty claims fail on "where's the receipt", not eligibility.
They forwards a card or bank statement PDF/CSV and Otto reconciles every line against the receipt ledger, reporting only the orphans — charges with no matching email; that's exactly where forgotten subscriptions, duplicate billing and fraud hide, and it's unfindable by eye across two countries' cards.
Invoices detected in a scan get their PDF downloaded, renamed canonically (`2026-08-11 — Enel — 84,30 EUR — invoice.pdf`), filed into a year/type folder in Drive, and their fields stored with the EUR/BRL amount at that day's rate; "how much did I pay Enel this year" and "where's the contract" become recall questions.