Every small company receives invoices. From suppliers, freelancers, landlords, phone companies, software vendors. They arrive by email or through the data-mailbox system as PDFs. And then someone — usually the same person, every month — sits down at Pohoda or Fakturoid and retypes: supplier name, amount, due date, invoice number, VAT. Three minutes per invoice, forty invoices a month. That is two hours of pure, repeated work where mistakes are easy to make.
The work nobody wants to do
Retyping invoices is not difficult. That is exactly the problem. It is work that demands attention, offers no judgement, and scales with the company in the worst possible way. Every new invoice is the same action as the last one. The more invoices the company receives, the more hours go into copying.
Errors wait in every fifth field. A mistyped invoice number, a misread VAT amount, a date entered in the wrong column. Most mistakes are caught during reconciliation — but catching them also costs time. And occasionally an error gets through to payment.
Month-end close, in brief: download invoices from email, open Pohoda, retype, save, repeat. By the end of the day your hands are full — and nothing new has been made.
— A routine that plays out in thousands of companies every month
What connecting invoices to accounting actually means
The AI stack connection works like this: one small MCP server watches the agreed input — an inbox, a folder, a data mailbox. When a new invoice PDF arrives, it passes the document to Claude. Claude reads the file, extracts the structured fields (supplier, company ID, net amount, VAT, total, due date, invoice number, variable symbol) and prepares a record in the format Pohoda or Fakturoid expects. That record goes into an approval queue.
The entire transfer runs under the identity of the user who started the MCP server. Claude never sees more than that person would see themselves. The accounting system receives the record exactly as if a human hand had typed it — but that hand only clicks "approve" instead of retyping.
Concretely: Pohoda and Fakturoid
Pohoda from Stormware has an XML import interface and a REST API that accepts incoming invoice records. Fakturoid offers a full REST API for creating documents. Both systems stay exactly where they are — you are not changing software or workflow for the rest of the company. The bridge is added alongside. A company with fifty incoming invoices a month that currently spends four hours retyping would, after the bridge is in place, spend roughly thirty minutes reviewing and approving proposed records.
- Claude reads PDF invoices — including those with non-standard layouts, different fonts, or handwritten values
- It extracts the key fields: supplier, company ID/VAT number, invoice number, date, due date, net amount, VAT, total, variable symbol
- The record is prepared in the structure Pohoda or Fakturoid accepts via API
- Invoices with ambiguities or amounts that do not match expectations are moved to a manual review queue
- Every transfer carries the identity of the logged-in user — no shared key, no cache outside your infrastructure
A sole-trader accountant or a freelancer handling invoices for three clients: instead of three blocks of retyping each month, they review three queues of proposed records. The invoice work shrinks to its decision-making part — and that part is as small as the invoices are standard.
What Claude will not do with invoices — and why that is a good thing
Claude does not approve invoices. It does not judge whether they match a purchase order. It does not know whether the supplier actually delivered the goods or service being billed. It does not send payments. These things stay with a person — and rightly so.
The boundary is not a weakness in the system. It is the reason the system can be trusted. The bridge handles the transcription — the most repeated, least valuable part of the work. Checking factual accuracy and authorising payment are decisions that require context Claude cannot derive from the invoice alone. Keeping these two things separate is deliberate.
What it would take to set it up
One MCP server. A connection to your incoming invoice channel — the email inbox or folder where PDFs arrive. An API connection to your accounting system, whether Pohoda or Fakturoid. It all runs on your infrastructure, under your control. This is not a year-long project or a software replacement. It is a bridge added alongside what you already have.
What is left
The model is not the bottleneck. Claude can read invoices reliably — that part is solved. The bottleneck is the gap between the received invoice and the accounting system. That gap is crossed manually in every company every month. We close that gap.
If you are curious how a bridge like this would work for your invoices and your system, write to us. A short call is enough to find out whether it makes sense and what it would actually take to set it up at your company.