Every week, the same ritual: open Pohoda, transcribe figures into Excel, guess which customers will pay on time and which will not, and try to assemble a rough outlook for the next fortnight. It takes hours and the result is still just an estimate. Yet all the data you need is already sitting in Pohoda — it just has no way to reach anything capable of reasoning about it.
The work nobody wants
A cash-flow forecast is not complex analysis. It is a straightforward sum: what comes in, what goes out, and when. Pohoda holds all of it — open issued invoices, due dates, the payment history of each customer, recurring liabilities such as rent or utility advances. The problem is that none of this data is in a form that can be used without first exporting it.
An export means a CSV or a spreadsheet, and a spreadsheet means manual work. Someone has to remember whether the customer whose invoice falls due next Thursday is the kind that pays on the day or the kind that arrives three weeks late. That is not maths — it is memory and experience, and eventually both run short.
I copied the numbers from Pohoda into Excel, colour-coded by how likely each customer was to pay, then recalculated three times because another invoice arrived mid-way. Two days later the forecast was already out of date.
— Owner of a manufacturing firm, fifteen employees — an abridged account of a weekly routine
What "connected" actually means
AI stack builds one MCP server between Pohoda and Claude. The server talks to Pohoda through its mServer interface — under your identity, with your permissions. Claude sees exactly what you would see if you opened Pohoda yourself: your invoices, your payments, your counterparties. No copy of your data on a third-party server, no indexing in an AI vendor's cloud.
The forecast then works like a conversation. You type: "Give me a cash-flow summary for the next fourteen days — factor in who historically pays late." Claude opens the MCP bridge, reads the open invoices, checks the payment history per customer, and returns a structured outlook. No export, no waiting, no spreadsheet.
Concretely: Pohoda and customer payment behaviour
Pohoda stores every received payment against an invoice — due date, actual payment date, customer name. From that you can calculate the average delay per counterparty over the past twelve months. A firm with ten regular customers typically has hundreds of such records in Pohoda. Claude does not need them all at once — a simple question such as "How long do we usually wait for payment from company XY?" is enough. The MCP server computes the answer from live data; Claude folds it into the forecast.
- Open issued invoices — who, how much, when due
- Historical due-date deviations by customer — who pays late and by how many days
- Recurring received invoices — rent, utilities, subscriptions, VAT advances
- Seasonal patterns — months when revenue historically dips or peaks
- Scheduled VAT returns — the predictable quarterly liquidity hit
As an illustrative example: a small trading company with annual revenue around CZK 15 million has four years of data in Pohoda. Claude uses it to produce a weekly outlook — shifting the expected receipt for habitually late payers by their average delay. The result is not a guarantee, but it is considerably more accurate than a table assembled by hand.
What a Claude cash-flow forecast will not do — and why that's good
Claude does not send reminders, approve invoices, or decide which liabilities to pay first. The forecast is a working document. What you do with it depends on the state of the business, the relationship with the customer, strategy — things that are not in Pohoda and never will be.
This limitation is the reason to trust the system. The bridge does not act on your behalf — it assembles the picture that would otherwise take you hours. The decision, the prioritisation, the phone call to the customer: those stay with you. That is how it should work.
What it would take
One MCP server for Pohoda. It runs on your infrastructure — not on AI stack servers, not in Anthropic's cloud. It connects to Pohoda via the mServer interface that STORMWARE ships as standard. Setting up the right permissions takes you or your IT person an afternoon. There is no year-long implementation project, no data migration.
What's left
The model is not the bottleneck. Claude can handle numbers, payment histories, conditional reasoning — that part is fine. The bottleneck is the gap between Claude and the data your company has been building in Pohoda for years. An MCP server closes that gap. Nothing more, nothing less.
Write to us — a short call is enough to understand how your Pohoda instance is set up, what you need in a cash-flow outlook, and how quickly it can go live.