Automatic invoices without manual entry are still a distant idea for many Czech companies. The problem is not technical. The problem is that order data sits in one place and the invoice must exist somewhere else. Between those two places stands a person with a keyboard.
The work nobody wants to do
It goes like this: an order arrives. Someone opens it in the e-shop or CRM, manually copies the line items into Pohoda, checks the VAT rate, adds the order number as the variable symbol, and saves the invoice. Then sends it. Then does it again for the next order.
One invoice takes ten minutes. Ten invoices a day is an hour. During a seasonal rush it stops being manageable for one person and the company hires a temp or pushes the accountant into overtime. And yet every one of those invoices contains data the company already has. Just in a different place.
The order came in at eight in the morning. The invoice went out at eight-oh-two. The accountant never opened her laptop that morning.
— Description of post-deployment state, illustrative example from a B2B e-shop
What automatic invoicing via Claude and MCP actually means
The pattern is not new in the sense that import scripts have existed for twenty years. They break at the first exception. The pattern we build is different. Claude receives structured order data, understands its context, assembles an invoice according to rules the company defines, and writes it directly into Pohoda via an MCP server using Pohoda's XML interface.
The MCP server carries the identity of the user who authorised the automation. Claude never sees more than that person would see themselves. The invoice is created in Pohoda under their permissions, in the correct document series, with the correct VAT rate. No data copy, no third-party system, no vendor cache.
Concretely: connecting an e-shop to Pohoda
Take a company on Shoptet with fifty orders a day. Shoptet has an API, Pohoda has an XML import interface. Until now a person stood between them. After deploying the MCP server it works like this: a new order in Shoptet triggers an event, Claude reads its data, assembles an XML document in the format Pohoda accepts, and the MCP server imports it. The invoice exists in Pohoda within two minutes of the order being received.
- Claude reads structured order data (line items, prices, customer, delivery address)
- Applies company rules: VAT rate, document series, payment terms, invoice text
- Assembles XML in the Pohoda format and hands it to the MCP server
- MCP server imports the invoice under the authorised user account
- Pohoda books the invoice; the document number returns to the order system as confirmation
For a smaller company or freelancer billing from a time-tracking system the same pattern applies. Claude reads the timesheet, assembles the invoice and writes it into Fakturoid. The rules are the same; only the source data and target system differ.
What automatic invoicing will not do, and why that is a feature
Claude does not invent payment terms. It does not extend credit to customers with a history of late payments. It does not approve invoices above a credit limit. Those exceptions go into a queue for a person with context and decision authority.
That is not a limitation. It is the reason the whole thing works. Automating routine work and maintaining human oversight of exceptions are two distinct things. Mixing them is a mistake in both directions. Routine work overwhelms a person with unnecessary effort. Exceptions require the kind of judgement a model does not have.
What it would take
One MCP server that knows how to talk to Pohoda via its XML interface, and one that reads orders from the source system. Both run on the customer's own infrastructure, not ours. Claude gets access through the permissions of a specific user account. Configuring the rules takes one working day, deployment takes a second.
What's left
The model is not the bottleneck. Claude can assemble an invoice from structured data faster and with lower error rates than a person with a keyboard. The bottleneck is the gap between the order system and Pohoda. That gap is what we close.
Write to us. A short call is enough to establish what your system produces and what Pohoda expects on input. The rest is infrastructure.