The unified accounting API powering B2B fintechs

What links these platforms is a dependency rather than a feature set. An accounts payable product delivers its value at the moment the approved bill appears in the customer's ledger. A collections product cannot start until it knows which invoices are actually overdue. A spend platform produces entries that have to be filed against real accounts with real tax codes. In each case the accounting system sits inside the product rather than beside it, which is why integration coverage decides deals in this industry and rarely decides them anywhere else.

The Tipalti case study describes what that costs from the inside. Its rollout started in the Netherlands with Exact Online, the system most of that local mid-market keeps its books in, and moved into DACH with DATEV, where the requirements are different enough that local product knowledge is its own cost line. Tipalti's own conclusion was that building and maintaining a European integration layer in-house would not produce a viable business case, which is a sentence worth reading twice if your roadmap currently assumes it would.

The pattern repeats per market rather than per system. Entering France means Pennylane and the systems around it, Sweden means Fortnox, Spain means its own set. None of that is exotic, and all of it is avoidable work, because the market a customer is in changes which system Maesn talks to and does not change what your code sends. Alongside Exact Online, the full system directory has a country filter, so you can check a market before you commit a quarter to it.

Two of the eleven have the whole story on record, and Paywise is the useful one if you are weighing a build: it attempted a single accounting integration in-house, found the work considerably beyond what it had planned and completed the switch in less than one sprint. What the table is not is a shortlist. Every category in it is one Maesn already publishes for a customer, so the categories missing from it are real gaps rather than modesty.

The distinction that matters most in this industry is between delivering data and computing on it. Maesn delivers the journal history, the accounts, the balances and the open items in one shape. Turning that into a liquidity forecast, a credit decision or a cash position is your product, and it should be, because that is the part your customers are paying you for.

Bank data is the case where the direction decides everything, and this page had it the wrong way round until 2026-08-10. Posting transactions into a customer's ledger is documented at four systems and is its own use case, with the certification question attached to it; reading them back out has no endpoint at all. So a fintech takes the transactions from a banking provider and hands them on through here rather than sourcing them here. The boundary that holds without any qualification is the one above it: turning that data into a forecast, a limit or a cash position is your product. The same applies to keeping data current, where freshness comes from a delta filter on the GET endpoints and from one webhook model with a normalised payload, rather than from a store of your customers' data on our side, which is what the security posture of a subprocessor to regulated companies requires. What is kept is the record that a transfer happened, not the data that moved.

If you want the mechanics rather than the argument, the accounts payable guide is the shortest complete example: five documented steps, the endpoint behind each one and the point where the documentation hands a decision back to you. The same five steps seen from the side of the team that has to ship them are on the page for product and engineering.