maesn
By industry

B2B fintech ends up in someone else's general ledger

Payables, receivables, collections, spend: whichever process your platform automates, it only counts once it lands in the accounting system your customer keeps their books in. Maesn connects to those systems through one integration, in both directions.

Book a demoRead the docs
Your platformboth directions
what you read
Customers
/customers
Suppliers
/suppliers
Chart of accounts
/accounts
Tax rates
/taxRates
what you write
Invoices
/invoices
Bills
/bills
Payments
/payments
Journal entries
/journalEntries
one integration

The general ledger of your customer, reached through one connection instead of one per system.

Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinProvetHeroHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinProvetHeroHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

The general ledger changes with every market you enter

A fintech scaling across Europe meets a new accounting market in every country it enters. This is the count per market from the live system list.

Market
The ledger your customers there keep
  • Netherlands7Exact Online, Twinfield, Moneybird and 4 more
  • Germany11DATEV Unternehmen Online, DATEV Rechnungswesen, sevdesk and 8 more
  • France5Pennylane, Sage Active, Sage Accounting and 2 more
  • Sweden3Fortnox, Dynamics 365 Business Central, odoo
  • Spain5Sage Active, Sage Accounting, Holded and 2 more
  • United Kingdom8Twinfield, Sage Accounting, FreeAgent and 5 more
Counted from the live system list, so the number next to each market is the number of connected systems that serve it, not a selection.

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 general ledger 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.

How Maesn solves it

One opening sequence for payables, receivables and invoicing

Put the documented recipes for accounts payable, accounts receivable and invoice creation next to each other and something useful shows up. They begin the same way. Synchronize the contacts, read the chart of accounts, read the tax rates, read the dimensions if the customer uses them. Only the last step or two actually differ.

Accounts payable
docs /use-cases/accounts-payable
  1. Sync contacts first/suppliers
  2. Chart of accounts/accounts
  3. Tax rates/taxRates
  4. Dimensionsoptional/dimensions
  5. Create a billPOST /bills
  6. Create a paymentPOST /payments
Accounts receivable
docs /use-cases/accounts-receivable
  1. Sync contacts first/customers
  2. Chart of accounts/accounts
  3. Tax rates/taxRates
  4. Dimensionsoptional/dimensions
  5. Create an invoicePOST /invoices
  6. Create a paymentPOST /payments
Invoice creation
docs /use-cases/create-invoices
  1. Sync contacts first/customers
  2. Chart of accountsoptional/accounts
  3. Tax ratesoptional/taxRates
  4. Itemsoptional/items
  5. Create the invoicePOST /invoices
the same readswhere the recipes differ

The requirement underneath all three is bilateral rather than one-directional. Reading master data lets your interface show your customer their own accounts and counterparties instead of a translation of them. Writing movement data puts the result of your process where their accountant will look for it. Both travel over the same connection and the same authorization, and both arrive through one normalized data model rather than in each vendor's own vocabulary.

The consequence is the part worth planning around. If your platform runs payables today and takes on receivables next year, the second module is largely work you have already done, because the reads it depends on are the reads you built for the first one. That only holds when both sit on one data model. Build each integration directly against a vendor API and the overlap disappears, because the second module has to rediscover the same four reads in that vendor's own shape, and then again in the next vendor's.

It is also why the first step is the one to take seriously. Contact synchronization comes first in all three recipes for a practical reason: everything after it references a counterparty, so if your records and the accounting platform disagree about who that supplier or customer is, the write either fails or quietly creates a duplicate for somebody to clean up. The documented reconciliation sequence treats it as its own piece of work rather than a preliminary, and so should any roadmap that has more than one module on it.

Where a single installation carries a field or an object the shared schema does not, reaching past the model covers it without forking your integration, and the identifiers that decide which tenant a call belongs to are handled by one authentication layer rather than per vendor.

What you get

Seven finance processes on one integration

Each of these is documented as its own sequence. What they have in common is visible in the middle column: the same two objects carry almost all of them, which is why the second process costs a fraction of the first.

Objects per process as the documented recipe reads and writes them. chart of accounts and tax rates appear in 5 of these 7.

There is a commercial side to this that engineering conversations tend to skip. Each of the systems behind those processes runs a marketplace, and integrating through Maesn opens a certified listing in it under your own brand, your name shown to the end customer at the moment they connect and co-marketing with the vendor. The integration is the entry ticket; the distribution is what it is worth.

References

Eleven fintech platforms already run on this

B2B fintech covers a set of platforms that each automate a different part of the financial process and then have to agree with the same system of record.

Fintech categories already running on Maesn
  • Accounts payable automationTipalticase study
  • Debt collectionPaywisecase study
  • Receivables managementDebtist
  • Expense managementFindity
  • Spend managementSpendOne
  • Embedded financeTilta
  • Financial reportingNoCFO
  • Tax automationSmarta Steuern
  • Financial software, broaderRally, Quid, ROKET
Each category is the one Maesn publishes for that customer on its own case-study pages. Two of them have a full case study, the rest are named customers.

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.

Key facts

B2B fintech object coverage, system by system

These are the objects the recipes above touch, with reads and writes listed separately and with what is supported today kept apart from what a system's own documentation marks on demand.

Across the 29 connected systems
What you needTodayOn demandSystem cannot
Read customers2027
Read suppliers1928
Read the chart of accounts1982
Read tax rates12143
Read dimensions3179
Read invoices13142
Create customers1649
Create suppliers14411
Create invoices10172
Create bills3224
Create journal entries10118
Three columns and no total, because averaging them would hide the thing you need. On demand means the object can be implemented for you and is not available today.

Two rows deserve a comment rather than a number. Reading a counterparty is supported far more widely than creating one, which matters if your onboarding assumes it can write a missing supplier into the customer's system rather than asking them to. And dimensions are supported by fewer systems than the rest of the set, a fair reflection of how many accounting platforms treat classes and departments as an advanced feature rather than a default.

The right-hand column is the honest one. Where a target system has no concept of an object there is nothing to normalize and nothing to write to, and any integration layer reporting full coverage there would be reporting a wish. The middle column is what each system's own documentation marks as on demand, which means the object is technically feasible and can be implemented for you, and that it is not available today. It is not an availability promise, so it belongs in a conversation about the specific system you need rather than in a plan that assumes it. Reading these three columns together with how filtering and paging behave is the fastest way to size a market before you plan for it.

Where our job ends

We deliver the ledger data, you build the financial product

The people evaluating this are technical, and the gaps turn up during the review anyway. Naming them here is faster for everybody.

In the unified data model
  • Invoices and billsBoth directions, with their line items and the original document as sent.
  • Payments and open itemsWhat has already been settled, and what is still outstanding per invoice.
  • Journal entriesPosted one at a time or in bulk, each with attachments of its own too.
  • Chart of accounts and tax ratesYour customer's own structure, rather than a mapping we invented for it.
Not in the data model, and we say so
  • Bank feedsNot one connected system lists transaction reads as supported today.
  • Treasury managementThe accounts and the balances are there, the treasury logic is yours.
  • ForecastingMaesn delivers the history a forecast runs on, it does not compute one.
  • Categorization rulesThe docs assign these to you, because they encode your customer's policy.

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 feeds are the clearest case. Bank accounts are an object you can read, and transaction reads are marked supported at none of the connected systems today, so a fintech that needs bank transaction data gets it from a banking provider rather than from an accounting integration. The same applies to keeping data current: freshness comes from a delta filter on the GET endpoints and from one webhook model with a normalized 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. Read by role rather than by industry, the same ground is covered for product and engineering teams.

B2B Fintech FAQ

Common questions

We are a B2B fintech with one integration live. Why would we not build the next one ourselves?

Because the second one is rarely like the first. Every accounting system carries its own authentication model, its own pagination behaviour, its own idea of whether an endpoint answers immediately or asynchronously and its own annual breaking changes. Some assemble a single object out of several sequential calls. The first build is the cheap part, and the maintenance is what keeps arriving afterwards. What Maesn changes is that the second, fifth and twentieth system reach your code in the same shape as the first.

Which fintech categories are already running on Maesn?

Accounts payable automation, debt collection, receivables management, expense management, spend management, embedded finance, financial reporting and tax automation, plus several broader financial platforms. Those are the categories Maesn publishes for its own customers, and eleven platforms are named on this page. Two of them, Tipalti and Paywise, have a full case study with the endpoints they use.

Do you support writing as well as reading?

Yes, and for a fintech that is the point rather than a feature. Master data such as customers, suppliers, the chart of accounts and tax rates is read so your product can present the customer's own structure. Invoices, bills, payments and journal entries are written back so the result of your process lands in the books. The coverage table on this page reports both directions per object, separately, because the two are not equally supported everywhere.

Our platform runs accounts payable today and receivables next year. Does that mean a second integration project?

Not on the same data model. The documented recipes for accounts payable, accounts receivable and invoice creation open with the identical sequence: synchronize contacts, read the chart of accounts, read the tax rates, optionally read dimensions. Only the final write differs, POST /bills against POST /invoices. So the second module is mostly work you already did, which is not true if each integration was built directly against a vendor API.

Which system will our customers in the Netherlands or the DACH region actually be on?

That depends on the market, which is exactly the problem this industry runs into. Tipalti's rollout is the documented example: it started in the Netherlands with Exact Online, the most widely used accounting system in that local mid-market, and expanded into DACH with DATEV. The table on this page counts, per market, how many connected systems serve it, so you can check your own expansion sequence against it.

Can we offer the integration under our own brand?

Yes, and it goes further than a white label. You can get a certified app listing in the target system's marketplace published under your name, your name shown to the end customer at the moment they connect their accounting system and the authentication flow running fully inside your own interface. Co-marketing with the target systems is part of the same path. Maesn stays in the background.

Do you handle bank feeds?

No. Bank accounts exist as an object and you can read them at several systems, but transaction reads are marked supported at none of the connected systems today, so there is no feed behind it that we could pass on. If your product needs bank transaction data, that comes from a banking provider rather than from an accounting integration.

Where does Maesn stop and our product start?

Maesn absorbs everything that is specific to the target system: its authentication and token lifecycle, its vocabulary for a supplier or an account, the identifiers that say which tenant a call belongs to, the shape it wants a write in and the changes it ships every year. Your product keeps the decisions that encode your customer's accounting policy, and the documentation is explicit that categorization logic depends on your application. A layer that decided that for you would be guessing at a policy it cannot see.

We are a subprocessor to regulated companies. Does that work?

That is the position Maesn was built for. Infrastructure is hosted in Germany, ISO 27001 certified, GDPR compliant and DORA-ready, and API calls are processed in real time without storing end-customer data. What is retained is the record that a transfer happened, not the transferred data itself, which is usually the question a security review asks first.

How current is the data after the first sync?

You ask for what changed instead of comparing copies. The GET endpoints take a delta filter on the last-modified timestamp, so detecting change is a query rather than a diff you build and store yourself. Where the target system emits events, webhooks do the same job with less traffic, and the payload reaches you in the same normalized shape whichever system sent it.

Can we migrate integrations we already built in-house?

Yes. Maesn can replace an existing provider or an in-house integration while preserving what that integration did, and the usual reason teams do it is not the first system but the maintenance across all of them. Paywise is the documented shape of that decision: it started building against sevDesk itself, found the effort well beyond what it had planned and completed the switch in less than one sprint.
Related industries
SaaSSoftware that manages the work and then has to bill it.Learn moreTravel PlatformsTravel bookings that have to land as correct postings.Learn moreBanks & Business LendersUnderwrite and monitor on data straight from the books.Learn more

Build once on the Unified API.

See how B2B fintech integration works for your integration, or dive into the technical reference.

Book a demoRead the docs