Agicap gets its accounting data through Maesn instead of maintaining it.
Agicap is a cash flow and liquidity platform for the office of the CFO: forecasting, payments and transfers, collections, receivables, payables and bank reconciliation on one surface. It had already written its own accounting integrations, and what changed the decision was not building them, it was keeping them running.
Who Agicap is, and which part is ours
- Website
- agicap.com
- About Agicap
- A French cash flow and liquidity platform with over 8.000 clients in 12 countries, which describes itself as Europe's leading provider of cash flow management software for SMBs and mid-market companies. Its own summary: the platform connecting banking and accounting flows to unlock trapped liquidity.
- Scope
- Cash management and forecasting, payments and transfers, collections, accounts receivable, accounts payable and payment reconciliation. The office of the CFO end to end rather than one step of it.
- Use case
- Treasury and financial planning on live ledger data, plus reconciliation written back as bookings. The workflow itself, independent of any one platform, is on the payment reconciliation page, and the planning half on financial analysis and forecasting.
- Previous solution
- Integrations built in-house. The decision to work with a partner came from the maintenance they needed and the overhead around it, not from the first build.
- The bank side
- Agicap's own, and it stays that way: an EBICS and PSD2 connection. Its own site names EBICS, SWIFT, Host-to-Host and SFTP for the banks, and Open Banking APIs beside them.
Maintenance is the part nobody quotes
An integration is quoted as a build and lived with as an obligation. Agicap had shipped its own, which is why the argument here is not about the first connector but about the ones that were already live.
A treasury platform does not want one object out of an accounting system, it wants a set: what was booked, who it was booked against, what is still open. Every system names those differently, exposes them differently, and changes them on its own schedule. That is the work that does not end when the connector ships, and it is the reason Agicap decided the accounting side was not the place to spend its own engineering.
The spread below is the same set measured across the 30+ systems Maesn connects, and it is what an in-house team would be signing up for once per system. Two of the four are deep, two are narrow, and the narrow ones are narrow because of what the target systems expose rather than what an integration asks for.
Journal entries as the standard read, twelve more on request. The ledger movement itself, with its accounts and its lines.
The counterparty behind a receivable, which is what turns an amount into a name a collections workflow can use.
Standard on Exact Online and Business Central, on request on 22 more. What is still outstanding, straight from the ledger.
No system exposes them as a standard read, 21 on request. Agicap does not need them from here: it has its own bank connection.
The ledger arrives as data, the bank stays where it is
The division is the point. Agicap keeps the side it has invested in, and takes the side that would cost it a connector per customer system through one connection.
Reading is the larger half: bookings, customer records and open items, normalised into one shape, so a forecast is built on the same fields whatever the customer runs. One authentication covers getting in, and the part that decides whether a connector needs an owner is what happens when a system changes or goes down, which is error handling rather than a feature anybody writes on a roadmap.
Writing is where the reconciliation lands. Agicap matches what the bank shows against what the ledger says, and the result goes back as a booking. Journal entries can be created on ten of the 30+ systems, and counting the other documented write paths with them, booking proposals, payments and open transactions, seventeen of the 30+ can take a write of some kind.
The two shapes Agicap runs need different things from the target system. Where both sides are banked and Agicap posts the share that has to be consolidated, the system has to accept an open transaction rather than a finished booking, and four of the 30+ do: DATEV Unternehmen Online, Exact Online, Lexware Office and sevdesk. Where Agicap is the end-to-end platform, the ledger is the last layer instead, and what it needs is a clean booking rather than a stream.
The maintenance moved to the other side of the API
Nothing about Agicap's product changed. What changed is who carries the accounting connections when a system ships a release nobody asked for.
The reason this decision is worth reading twice is that Agicap was not starting from zero. It had built integrations, so it knew exactly what it was buying out of: not the first build, which any competent team manages, but the standing obligation behind every connector that is already live. That is an engineering argument before it is a commercial one, and it is the same one on the page for product and engineering teams.
What the platform gets in exchange is room to be end to end. A cash forecast is only as good as the ledger behind it, collections only work with the counterparty attached, and reconciliation is worthless if the result cannot be written back. Those are three different objects moving in two directions, and they now arrive in one shape from every system a customer happens to keep.
Common questions
What does Agicap read through Maesn?
Why do the bank movements not come through Maesn as well?
What gets written back?
What happens when both sides have a bank connection?
And when Agicap is the end-to-end platform?
Could another treasury platform use the same setup?
Automates the full accounts payable cycle and posts every payment back into the customer's ERP.Read the case study
Turns tracked project time into draft invoices inside the accounting system the customer already runs.Read the case study
Pulls overdue invoices out of the customer's ledger so collection can start without a manual upload.Read the case study