maesn
By function

Product and engineering teams ship one integration, not one per accounting system

Your customers keep their books in whichever system they already chose, and that choice is theirs rather than yours. Maesn puts one REST API in front of all of them, so what you ship is one integration instead of dozens.

Book a demoRead the docs
Read a customer's invoices
without a unified layer
  • DATEVOAuth + client credentials, XML
  • Xerotenant id per connection, REST
  • sevdeskAPI token, its own field names
  • and one client per system after that
with Maesn
GET /invoices
One call, one shape, one authentication. The system behind it is a value in the header.
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
4.8on G24.8 out of 5 stars on G2
The problem

Every system executes the same use-case, but they all do it differently

Every system reinvented the wheel: auth methods are different, object structure, multi-API calls required to retrieve or post one dataset, webhooks in availability or in how they work, user-based versus app-based, sync versus async API calls, API technologies that differ between REST, SOAP and XML/CSV uploads, qualification processes, limited documentation, missing sandboxes, different paginations, rate limits, data formats, developer access and much more.

7systems

require seven different sets of mandatory fields for the same expense

3field names

is how many ways those systems name the account the line books to

3 / 4net / gross

expect the amount net, against four that expect it gross, and the difference is the tax

One object, counted across the systems that support it. That is the work an estimate per connector does not contain, and expense sync sets it out field by field.

Integrating to a new system is always about getting to know new ways to build something, understanding the details and exploring the quirks that are not documented. That is time consuming and often something that can only be explored if you are getting really deep into a system and build up a technology partnership.

But is that really what you want to do? Especially if that is exactly what we have done already?

How Maesn solves it

Everything unified, as if it were one system only

The same call, every system
GET /invoices?limit=50
 
X-API-KEY:     <x-api-key>       # your identifier against us
X-ACCOUNT-KEY: <x-account-key>   # your customers' identifier - received during authentication
 
# The same call for every connected system. Which system answers
# is decided by the account key, not by a branch in your code.

You integrate once, against one common data model. An invoice has the same field names and the same types whether it came from DATEV, Xero or sevdesk, and your product logic stops carrying a branch per vendor. A call like GET /invoices stays the same call, and which system answers it is a value you pass rather than a code path you maintain.

Connecting a customer is one flow rather than a project. Unified authentication absorbs the vendor differences that are real, an app registration here, a tenant selected during connect there, and tokens stay on our side. Where one installation carries a field nobody else asks for, customisation handling reaches past the model to the system's own endpoint, so an exception stays one request rather than a fork.

What you get

Everything engineers need to go live in days

Our Maesn features aim to unify everything that is possible, and for any use-case specific challenges we are there to help you.

  • Common Data Model

    A field-name translation per vendor, and the mapping table that grows with every system.

  • Unified Authentication

    A vendor login per system, plus the token lifecycle behind each one.

  • Unified Pagination & Filtering

    The paging loop per system, and the nightly full re-read that stands in for asking what changed.

  • Unified Webhooks

    One subscription and one event body, instead of a different vendor model per integration.

  • Unified Error Handling

    A failure dialect per system, and the support runbook that grows with every one you add.

  • Asynchronous Processing

    Your own rate limiting, sequencing and task tracking for the month-end run that does not behave.

  • Unified Logging & Monitoring

    Guessing which system failed for which customer at which moment, from your own logs.

  • Customisation Handling

    A fork when one installation carries a field nobody else asks for.

  • MCP Server

    Building an agent surface over accounting data yourself, once your product needs one.

Some systems don’t offer any developer sandboxes. For those, we run test environments that you can use.

  • DATEV Unternehmen Online
  • DATEV Rechnungswesen
  • Dynamics 365 Business Central
  • Fortnox
  • Twinfield
  • Qonto
  • Pennylane
  • Sage Active
  • Xentral
  • Abacus
  • AbaBau

See all Sandboxes at docs.maesn.com/sandboxes

References

Made for engineers

HERO Software

HERO Software runs the back office for craft businesses, from the quote to the invoice, and more than 40.000 tradespeople work in it.

“The support provided is truly first class, with impressively quick response times. The documentation is thorough and easy to follow, which made integration a smooth process for me. I also appreciate the wide range of accounting integrations and endpoints available. It's clear that the endpoints are continuously being developed and expanded, which adds even more value to the platform.”
Ricardas Kauneckas
Full Stack Engineer, HERO Software
Book a demoRead the case study
4.8on G24.8 out of 5 stars on G2
Where this ends

What arrives through the API, and what stays your product

A unified layer that is vague about its boundary costs more than one that is narrow about it.

Maesn delivers
  • One REST API and one object model across the connected systems
  • One connect flow per customer, plus tokens and their refresh
  • A sandbox per system, including the ones with no free trial
  • Vendor API changes absorbed centrally rather than in your release
  • One event model and one signed event body
Your product decides
  • When a record leaves your product, and what triggers it
  • Which account, tax rate or dimension a line belongs to
  • Reconciliation before a write, so a record is not written twice
  • What your users see when a target system rejects something
  • The workflow itself, from the quote to the posting

The decisions on the right are the ones that depend on what you built, and they should stay there. What the layer removes is the part that is the same for every product and different for every system. Invoice creation is the shortest example of both halves in one workflow, and the directory of connected systems shows what the right-hand column has to hold up against. How requests are processed and what is kept on the way through is on the security page.

Product & Engineering FAQ

Common questions

Why use Maesn instead of building the integrations ourselves?

Because the cost is not the first integration, it is the shape of the second one. Each accounting system has its own authentication, its own field names and its own idea of paging, so a second integration is a second client rather than a second configuration. With Maesn you write one client against one object model, and which system sits behind a call is a value in the request rather than a branch in your code.

Do we still have to deal with each system's data formats?

No, that is the part the common data model absorbs. Objects arrive with the same field names and the same types regardless of what the system underneath calls them or how it serialises them. Where a system holds something the model has no field for, you reach it through passthrough or raw data rather than losing it.

Do we get sandboxes, and for which systems?

Yes, and the useful part is which ones. The sandbox table in the documentation lists 30 systems and marks a Maesn-provided sandbox on every one of them, while only 19 of those systems offer a free trial of their own. For the remaining 11, among them both DATEV products, Fortnox and Twinfield, the Maesn sandbox is the only way to write code against the system before any partner agreement exists. Maesn-owned sandboxes populated with test data are requested rather than self-serve.

Do we have to manage access tokens ourselves?

No. Tokens, refreshes and the per-system expiry rules sit with Maesn, and a burst of parallel traffic during a refresh is sequenced per tenant so the connection stays intact. Your product holds one account key per customer connection and does not implement a vendor's token lifecycle.

Is authentication the same across systems?

The interface your product uses is the same for all of them: one flow to connect a customer, one account key afterwards. What differs underneath is real and documented per system, because some vendors need an app registration and some need a tenant selected during the connect step, and that difference is handled in the flow rather than passed on to you.

How do webhooks work here?

There is one event model and one signed event body rather than one per vendor, so your handler does not change when you add a system. Which systems emit native events and what happens for the ones that do not is set out on the webhooks page, and it is worth reading before you design around events rather than reads.

Does the API support filtering, ordering and pagination?

Through the same two parameters and the same delta filter everywhere it is available, which is what makes a paging loop reusable across integrations. It is not universal, and we do not claim it is: the capability has to exist in the system underneath, so not every resource supports all three. The filtering page states per case which is which.

What happens when an ERP is heavily customised?

Most of it lands in mapping or free-text fields inside your own integration setup. Beyond that there are two documented ways past the model: an authenticated passthrough call to any endpoint the system exposes, and raw data that returns whatever the system returns, unfiltered. You can mix normalised endpoints and raw access in the same integration.

What happens when a vendor changes its API?

Maesn is a technology partner with the systems it connects to, so changes are seen and absorbed centrally rather than in your release. A field a vendor renames or an endpoint it versions does not become a ticket in your backlog. That is the maintenance argument for a unified layer, and it is the one that compounds after the first year rather than during the first build.

Is the documentation in English?

Yes, all of it, and that is deliberate rather than incidental: several of these systems document themselves only in German, Swedish or Dutch. The Maesn reference is one English source for all of them, which is what removes the reverse-engineering step from a first integration.
Maesn for other teams
Go-to-MarketAnswer which systems you support, without asking.Learn moreCustomer SuccessSee every request, response and webhook per customer.Learn moreFinancial TeamsRead the books your group's entities keep separately.Learn more

Build once on the Unified API.

See how one integration across every system works for your integration, or dive into the technical reference.

Book a demoRead the docs