Hunting receipts with an AI agent: invoices from mailboxes and online shops, collected automatically
How a Claude agent finds the receipts for open bank transactions on its own – across several mailboxes and straight from online-shop customer accounts – and books them via the Lexware Office API. The agent collects and books, the human decides.
This is how I brought the books of my own companies up to date with a Claude agent, mail connectors, browser automation and the Lexware Office API. A use case, not a showcase: I apply the same patterns in data engineering pipelines for clients.
As managing director of two small companies, I want the receipts for open bank transactions to be collected automatically from my mailboxes and customer accounts and booked, so that I only decide the cases that genuinely need my decision.
Starting point
At the outset, the books showed more than 120 unmatched bank transactions. The real problem wasn’t booking – it was finding: receipts were scattered across several mailboxes, merchant portals, cloud billing consoles and PDF bank statements.
Many merchants don’t email an invoice at all, just a note saying “your invoice is available”. The PDF then sits in the merchant’s customer account and has to be downloaded one by one. That’s exactly the kind of chore that otherwise piles up.
On top of that, one detail costs time every month: the bank posts the VAT on interest and account fees as a separate transaction. A single statement thus turns into up to five bank transactions belonging to two receipts. The software’s automatic matching suggestion also regularly books the statement without tax – the input VAT would be lost.
The technical hurdle: the Lexware Office public API covers vouchers, contacts, categories and payments, but not bank transactions. Pure API automation isn’t enough.
Solution
A Claude agent works through three channels: the mailboxes via mail connectors, the browser for customer accounts and everything the API can’t do, and the Lexware Office API for vouchers and checks. A custom skill defines the order of work and how results are verified. There are two workflows.
A – Collecting receipts
- Read open bank transactions: amount, date, counterparty, reference.
- For each transaction, search every mailbox – by sender, amount, invoice number and a time window around the booking date. Take over PDF attachments.
- If the invoice only exists in a customer account, the agent opens the shop in the browser where I’m already signed in and downloads the invoice from the orders or invoices section.
- Check the receipt: amount, date, VAT – and above all the invoice recipient, i.e. which company.
- Create the voucher via the API, attach the PDF, then match the bank transaction.
- Anything that can’t be found goes onto the remaining list – optionally with a request email to the supplier that only goes out after approval.
B – Monthly bank close
- Read the month’s bank transactions in the web interface.
- Derive amounts from the reference text and check them against the statement, including the VAT net base.
- Create vouchers via the API, one for the loan and one for account fees.
- Immediately attach the bank statement as the voucher image.
- Only then match the bank transactions in the browser, including partial matches and early-payment discounts.
- Verify via the API: voucher image present, payment settled, open amount zero.
In both workflows, the order is not a detail. As soon as a bank transaction is attached to a voucher, the software locks any changes. A forgotten PDF then means: unmatch everything, upload, match again. After finalisation, only a reversal is possible.
Guardrails: what stays with the human
The agent collects, prepares and books, but doesn’t make judgement calls. These rules were fixed from the start:
- Judgement stays with the human. Private or business, loans between the companies, missing receipts: the agent compiles the case with all the facts and asks.
- No logins by the agent. It only uses browser sessions where I’m already signed in. It never types passwords. In a customer account it only downloads invoices – it doesn’t order anything or change settings.
- Nothing irreversible. The agent doesn’t perform permanent deletions or GoBD reversals. It stops and presents the decision.
- No key in the chat. The API key lives in a protected file, and every run first checks that it is really connected to the right company.
- Recalculate instead of trusting. Every voucher is finally checked via the API against amount, tax, voucher image and open amount. The software’s automatic matching suggestions are never accepted blindly.
- Emails to suppliers only after approval. The agent requests missing invoices by email – but only once the text has been signed off.
Result
The backlog is cleared, and both receipt collection and the monthly close now run as repeatable workflows instead of an evening chore.
- Receipts collected from mailboxes and shops: invoices found across several mailboxes and many downloaded directly from more than a dozen merchant and cloud portals.
- More than 120 open bank transactions reviewed, booked and matched.
- Three monthly closes (July to September) booked with the same skill, including a clean split of interest and fees.
- Tax errors caught: the incorrect matching suggestion without input VAT came back every month and was detected and corrected every month.
- Cross-company error resolved: checking the invoice recipient revealed that one company’s invoice had accidentally been paid from the other’s account. The agent prepared the correction.
- A short list instead of a pile: what remains are a few cases with a clear question, such as a missing invoice that has already been requested.
Transfer
Accounting is only the domain here. The patterns are the same as for job onboarding or audit bots on data platforms.
- Fetch data where it lives. Receipts come from mailboxes, portals and consoles – just as data on a platform comes from many source systems. The agent searches across all sources and matches against a fixed key: the bank transaction.
- Existing sessions instead of new integrations. Where there’s neither an API nor an export, the session the human already has open is often enough. That opens up sources without an interface, without waiting for the vendor.
- API first, browser as a bridge. Where an API is missing, browser automation fills the gap.
- Process knowledge belongs in a skill, not in your head. Order, search rules, formulas, edge cases and worked examples are versioned in one place. The next run doesn’t start from zero.
- Verification is part of the workflow. Every step ends with a machine check, not with “looks good”.
- A clear line between executing and deciding. The agent does the legwork, the human keeps the responsibility. That’s exactly what makes it viable in regulated processes such as GoBD-compliant bookkeeping.
Stack: Claude · Mail connectors (Microsoft 365, Gmail) · Claude in Chrome · Lexware Office API · Python