How We Automated Multi-Currency Invoice Processing with n8n, Claude and Notion

We’re a Romanian company that bills and gets billed in euros, dollars and lei. Every one of those invoices has to land in our books in RON, converted at the official National Bank of Romania (BNR) rate. For years that meant opening each PDF, reading it, retyping it, looking up the rate and doing the maths by hand.

Nobody enjoys that work, so it gets postponed. Then it happens all at once at month-end, when you’re tired and typos slip in. A wrong digit in an amount or the wrong day’s exchange rate doesn’t announce itself. It just sits in the books until someone reconciles and finds it.

So we automated it for ourselves first. This post explains how the pipeline works, and more usefully, the decisions that separate an invoice automation you can trust from one that quietly makes a mess.

If you’re an e-commerce brand or manufacturer buying from suppliers in one currency and reporting in another, the problem is the same. Only the names of the currencies change.

The one rule for the user

The whole system is built around a single instruction: put the invoice file in a folder, and that’s it.

No form to fill, no app to open, no fields to check. If a person has to do anything more than drop a file, the automation hasn’t done its job.

How the invoice pipeline works

The pipeline runs in n8n, reads invoices with Claude, and records everything in a Notion database. Here’s the journey of one invoice, from the folder to the books.

When anything goes wrong along the way, the invoice takes a different exit: an error log and a “failed” folder. More on that below, because it’s the part most invoice automations get wrong.

Reading the invoice is the easy part

Getting an AI model to pull an amount off a PDF takes an afternoon. Plenty of templates will do it. The hard part is everything around that step: making sure the number that reaches your books is correct, recorded once, and traceable. These are the six problems we had to solve.

1. The same invoice, recorded twice

Files get re-uploaded. Workflows re-run after a hiccup. Several invoices arrive at once and trigger several runs. Each of these can create a duplicate, and a duplicate in the books is worse than a missing entry, because nobody goes looking for it.

The fix is boring and essential: check before you create. Every file is looked up by its permanent Drive ID before any work starts. A file that’s already recorded is skipped, and the pipeline moves straight on to the next one. It’s the same principle we applied when connecting five systems for a UK manufacturer: every step that creates a record searches for it first.

2. Which side of the invoice are you on?

An invoice doesn’t say “income” or “expense” on it. It says who the seller is and who the buyer is. The pipeline tells Claude exactly who we are, so it can decide: if we issued it, it’s income; if we received it, it’s an expense.

This sounds trivial until you remember that a sign error on an invoice moves your profit in the wrong direction, twice.

3. The exchange rate has a date

This is the mistake we see most often in invoice automations, and we made it ourselves in the first version. It’s tempting to fetch “the” exchange rate and convert. But there’s no such thing. There’s the rate that applies to the date of the invoice, and every other rate is wrong.

An invoice from last Tuesday, processed today, must be converted at the rate valid last Tuesday. In Romania, the Fiscal Code’s methodological norms define that as the last rate BNR communicated before the operation, typically the previous banking day’s. Invoices dated on weekends or public holidays fall back to the last rate published before them.

So the pipeline reads BNR’s historical rates, finds the right day for each invoice, and stores both the rate and its publication date next to the converted amount. Anyone checking the books later can see exactly where the number came from. It also handles currencies BNR quotes per 100 units, like the Hungarian forint, which is an easy way to be wrong by a factor of 100.

Practice varies between accountants on which day to use, so the rule is a single setting we can switch. Check with yours before you copy ours.

4. AI output is a draft until it’s validated

Claude is very good at reading invoices. It is not infallible, and neither is a scanned PDF. So we never write what the model returns straight into the books.

Every field goes through validation first. Dates must be real calendar dates. Amounts must be numbers, whether the invoice writes them the European or the English way. Currency codes must be real. Invoice type must be exactly income or expense. Categories must match our list. If the model can’t find a value, it’s told to say so instead of guessing, and a missing required field stops the invoice.

The principle: the automation moves information. It doesn’t make judgement calls it isn’t qualified to make.

5. Failures need to be loud and somewhere visible

The worst invoice automation is one that fails silently. A rate feed that’s down, an unreadable scan, a database that rejects a value: each one should stop that invoice and tell a person, never fill in a plausible-looking default.

Every stage that can fail is routed to the same place. The pipeline writes an entry to an error log in Notion: which file, which stage failed, the exact error, and the raw AI response where one exists. The file itself moves to a “failed” folder, so it can’t block the inbox or get retried endlessly. Once the problem is fixed, dropping the file back in the inbox reprocesses it.

One failed invoice never stops the others. The pipeline logs it and carries on with the rest of the batch. We took the same approach with Revolut chargebacks in Monday.com: what a retry can’t fix goes to a person.

6. Not every file is an invoice

People drop all sorts of things into folders. A Word document, a spreadsheet, a Google Doc. The pipeline checks the file type before it spends anything on it. PDFs and common image formats go through; anything else is logged as unsupported and set aside with a clear reason.

What it deliberately doesn’t do

Knowing where an automation stops is as important as what it does. Ours doesn’t:

• • Pay anything. It records invoices and their status. Money moves only when a person moves it.
  • Replace the accountant. It produces clean, traceable records an accountant can work from. Tax treatment and final bookkeeping decisions stay with a professional.
  • Break invoices into line items. For our books, the net total, VAT and category are what matter. A business that needs line-level detail, for example to reconcile stock, would extend the extraction.

It adapts to your stack

We used Notion because that’s where we keep our own books. The same pipeline can write to Xero, QuickBooks, a Google Sheet or a Romanian invoicing system, the way we connected SmartBill to Magento for a client. The inbox can be a shared folder, an email address, or both. The rate source can be the European Central Bank, or the Bank of England for a UK business.

What stays the same is the part that matters: duplicate protection, validation before writing, the right rate for the right date, and failures that land in front of a person.

Who this fits

• • E-commerce brands paying suppliers, platforms and ad networks in several currencies
  • Manufacturers buying materials abroad and reporting at home
  • Agencies and service businesses billing international clients
  • Accounting firms receiving client invoices in every format imaginable