maesn
By industry

Enterprises build their own tooling, then have to reach every entity's ledger

A group runs as many accounting systems as it has entities, and the software your own IT builds has to read and write all of them. One connection per entity, the same objects back.

Book a demoRead the docs
One groupFour of its entities
  • Group holdingMicrosoft Dynamics 365 BC
  • German operating companyDATEV Rechnungswesen
  • Dutch subsidiaryExact Online
  • Nordic subsidiaryFortnox
what your own systems read
The same objects, with the same field names, whichever entity answered.
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

The software is already built, the connection to each entity is not

Enterprises with their own IT rarely arrive asking for an application. They arrive with one they built or bought and extended, and with the same blocker underneath all of it.

Finance operations

Own tooling for payables, receivables and reconciliation, or a bought product extended in house.

Written to, in every entity

Analysis and forecasting

A BI stack the finance function already trusts, fed from every entity that closes its own books.

Read from, in every entity

Master data

One central place customers, suppliers and products are meant to come from, feeding everything else.

Both, and kept aligned

All three of those end at the same wall, and it is not a modelling problem. Each entity keeps its books in its own system, chosen locally, often before the group owned it. A holding on Microsoft Dynamics 365 Business Central and a subsidiary on Exact Online are two integrations before this and one after. Reaching one system is a project. Reaching eleven is a programme, and the eleventh arrives the week after an acquisition closes.

What makes it worse than a normal integration backlog is that the work does not end when the connection does. Accounting vendors change their interfaces on their own schedule, and a field that disappears in a spring release is a report that stops rendering on a Tuesday. That maintenance lands on the same internal team that was supposed to be building the tooling.

How Maesn solves it

One object model, and five problems you no longer solve per entity

For an internal team the interesting part is not what the API returns but what it takes off the roadmap. Each of these is a piece of work that otherwise repeats once per entity and once per vendor.

Together they are the reason a twelfth entity is a connection rather than a quarter of work. The MCP server sits on the same layer for the case where the thing asking the question is an agent rather than an application, including a local variant where a hosted component is not an option.

What you get

Six workflows on one integration, reading the same objects

Internal tooling rarely does one thing. The objects column below repeats itself, and that repetition is why six processes sit on one integration instead of six.

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

Consolidation is the one that most often arrives first, and it is rarely owned by the team that builds the connection. It sits with the finance function, who decide what a group figure has to reconcile to and which entities are in scope for a close. Agreeing that boundary with them before the first entity is connected is cheaper than agreeing it after the third.

Key facts

Master data is the case that runs in both directions

The workflows above mostly move in one direction. Customer, supplier and product records do not, and that is what makes them the harder half of an internal data programme.

  1. 01Theirs
    Every entity's system

    Customers, suppliers and products, each maintained locally

  2. 02Maesn
    One connection per entity

    Read and write, same objects and the same field names

  3. 03Yours
    Your central store

    The data lake or master data hub you already run

  4. 04Yours
    Everything downstream

    BI, the document system and the apps that ask for it

Where the master record lives and what it means are decisions we do not make.

The same customer exists in four systems under four spellings, and every one of them is somebody’s source of truth locally. Centralising that is a decision about governance rather than about pipes, and it is yours. What the connection provides is the part that has to work in both directions: customer and supplier records read and written in each entity’s system with the same fields, so the store in the middle can be fed and can feed back.

Which systems can actually do that, and for which objects, is not uniform. It is published per system in the integration directory rather than averaged, and for a group the number that counts is not how many systems support an object but whether every entity in scope does.

Where our job ends

We deliver the objects, your IT keeps the architecture

This buyer builds software for a living, so the useful thing is a clear line rather than a broad promise.

What Maesn absorbs
  • One shape for every entity's system
  • Authorization per entity
  • Each vendor's own vocabulary
  • Their yearly breaking changes
What stays yours
  • Where the master record lives
  • What a group figure reconciles to
  • Your data model and your store
  • Everything your auditor sees

Nothing here is an application. There is no consolidation engine, no reporting layer and no opinion about your warehouse, because a group that has built its own tooling does not want a second one underneath it. A currency translation, an intercompany elimination and a group chart of accounts are all decisions with your auditor attached, and they stay where that responsibility is.

The half we do carry is the half that never finishes. Vendor interfaces move, entities get acquired and divested, and a connection that worked in March is a support ticket in April. Holding the shape constant while the systems underneath it change is the work being handed over, and it is worth pricing against the internal roadmap it frees rather than against a first integration.

Enterprise FAQ

Common questions

Which enterprises already run on this?

None that Maesn publishes. The named customers on this site are software products, and no corporate IT department appears among them. What carries this page is the platform and the documented objects instead: what each connected system exposes is published per object and per direction, and the workflows are described endpoint by endpoint. If a comparable reference matters before you commit, that is a question for a call rather than for a page.

We already have an integration platform. Where does this sit?

Underneath it, on the accounting side. An iPaaS gives you the plumbing between systems you already reach; the work here is reaching the ledger in each entity at all, with one object model instead of one connector per vendor. Most groups keep their platform and treat this as the accounting source it calls, which is also why nothing here prescribes what runs on top.

Our entities do not all use the same accounting system. Is that a problem?

It is the reason to do this rather than an obstacle to it. Each entity connects to its own system and the objects come back with the same field names and the same types whichever one answered, so a subsidiary on a different vendor is a connection rather than a project. What differs per system is which objects it exposes, and that is published per system rather than averaged into a promise.

Can we write back, or is this read only?

Both, and for internal tooling the write direction is usually the point. The structural records an entity keeps, its accounts, its rates, its counterparties, come out so your software can show that entity as it actually is. What your process then produces goes back in as the postings and documents those books expect. Coverage is reported per object and per direction, because the two are far from equal everywhere.

How do we keep our central store in step without polling?

Through events. A subscription per connected entity reports what changed, so your store reacts instead of asking on a timer, and the systems whose vendors publish no native events are covered through the same unified model rather than left out of it. Where a full refresh is still needed, filtering by what changed since a timestamp is documented at some systems and not at others, which is a per-system planning question rather than a general answer.

Who inside the group usually owns this?

Two teams. The engineering side owns the connection, the credentials and the schedule. The finance function owns what the numbers mean, which entity is in scope for a close and what a consolidated figure has to reconcile to. Most delays in these projects are not technical, they come from that split being agreed after the first entity is connected rather than before.

Does this cover our ERP as well as accounting?

It covers what the connected systems expose, and for the systems on this list that is the accounting and finance side of them. Business Central and Exact Online are ERPs and are connected as such; a manufacturing module or a bespoke internal object is not part of the common model, though a field beyond it can still be reached where the system exposes it. The honest scope is the ledger and what sits directly around it.

Where does our data sit?

In each entity's system and in yours, and in no third place. Nothing that passes through is written down here beyond the fact that it moved, so there is no group ledger accumulating on our side for anyone to ask about. What an audit or supervisory conversation usually wants is four things: German hosting, ISO 27001, GDPR-compliant processing, and an audit trail that shows a transfer occurred without holding what it carried.
Related industries
B2B FintechPlatforms whose product depends on the general ledger.Learn moreBanks & Business LendersUnderwrite and monitor on data straight from the books.Learn moreTax AdvisorsPractices analysing client books that sit in every system.Learn more

Build once on the Unified API.

See how multi-entity accounting data works for your integration, or dive into the technical reference.

Book a demoRead the docs