maesn
By industry

Tax advisors read every client's ledger without asking for another export

A practice has as many accounting systems as it has clients. Maesn returns all of them in one shape, per mandate, once the client has authorised it.

Book a demoRead the docs
One practiceFour of its mandates
  • Client books at the practiceDATEV Rechnungswesen
  • Client prepares, practice booksDATEV Unternehmen Online
  • Client books in houseLexware Office
  • Client books in housesevdesk
what your analysis reads
One set of objects, in one shape, whichever of them a client keeps their books in.
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

The analysis a practice wants to sell runs on data it has to collect by hand

Practices are extending past the mandate itself into analysis, forecasting and reporting for their clients. The work that decides whether that is profitable happens before any of it: getting at the numbers.

  1. 01Ask

    The client, or the colleague who books them

  2. 02Export

    Out of whichever system that mandate uses

  3. 03Check

    Right period, right entity, right version

  4. 04Again

    Next month, and once per client

The cost is not the export. It is that the export is somebody’s task, so the service scales by hiring.

The ambition is not the constraint. A practice knows what a client’s figures mean better than any tool does, which is why the analysis is worth selling in the first place. The constraint is that the figures are not in one place. Some mandates are booked in the practice’s own system. Others are kept by the client, in whichever tool they picked years ago for reasons that had nothing to do with their advisor. Both are legitimate, and together they mean a practice serving three hundred clients is looking at a handful of different systems rather than one.

The second constraint is subtler and shows up later. Whether a practice licenses a product or builds its own, the thing being bought is access to client data, and every system it has to reach is a separate project with its own authentication, its own field names and its own annual changes. The first connection is a sprint. The tenth is a team.

How Maesn solves it

Secure, correct, reliable and current are four different pieces of work

Those four words are what a practice actually requires, and each of them is a promise anyone can make. They are worth something only if you can say what each one is measured by.

Secure

Nothing rests in between

  • No client data stored in transit
  • The log records that a transfer happened, not what was in it
  • German hosting, ISO 27001, GDPR-compliant processing
Correct

Each system’s own structure, kept

  • A chart of accounts arrives as that system publishes it
  • No field averaged across systems to look tidy
  • An object a system does not expose is reported as a gap
Reliable

Their release cycle, not yours

  • Vendor interface changes absorbed on our side
  • The shape your code reads stays constant
  • The recurring half of the work, and the half nobody estimates
Current

Fetched on request, not from a store

  • A read reflects the client’s system at that moment
  • Some systems document a changed-since filter, some do not
  • Where it is missing, a refresh re-reads the period

Two of those four have a page behind them rather than a sentence. The security posture sets out the certifications and the hosting instead of asserting them, and the common data model is what makes four systems readable side by side without flattening the differences that matter.

What you get

Four workflows on one connection, and they read the same objects

A practice does not run one process on client data, it runs several. Read down the objects column: the same handful recurs, which is why these are one integration rather than four.

Objects per process as the documented recipe reads and writes them.

The fourth one is the reason several practices start looking at all, and it is the one without a table row above, because it has no documented object recipe yet. Giving agents access to client accounting is not a data problem so much as a governance one: an agent that reads a ledger needs the same authorisation, the same scope and the same audit trail as any other caller. An agent pointed at a folder of exported spreadsheets has none of those, which is the version of this that most practices have already tried. Where the agent has to run without a hosted component in the path, the MCP server is documented in a local variant for exactly that requirement.

Key facts

In Germany the client base sits behind one cooperative

Any practice reading this in Germany already knows which system the conversation is about. The reason that concentration exists is structural rather than commercial.

DATEV, in its own published words
Legal form
Eingetragene Genossenschaft (eG)
Members
More than 40.000
Founded
1966, in Nuremberg

The cooperative describes its own purpose as digitising commercial processes im Dienst der steuerberatenden Berufe, in the service of the tax profession. Its members are that profession, which is the whole of the explanation: the software your clients’ books sit in is built by an organisation its own users own.

Legal form, membership and founding year from DATEV’s own company page, read on 11 August 2026.

An ordinary software vendor sells to a profession. A cooperative owned by that profession is the profession, organised differently. That is the whole reason the German picture looks the way it does: the software is not competing for the tax profession’s business, it belongs to it, and it has been following German tax and commercial law from the inside since 1966.

For an integration that concentration is good news and one caveat. The good news is that reaching most of a German client base means reaching a small number of systems well rather than a long tail badly. The caveat is that DATEV is two products with two different roles, and which one a mandate uses depends on who does the booking.

The practice books
DATEV Rechnungswesen

The Kanzlei-Rechnungswesen itself. The data sits where the work happens.

The client prepares, the practice books
DATEV Unternehmen Online

The exchange between the two, and the reason there are two products rather than one.

Both are connected, and the documented route describes them separately for that reason. The money pages carry the detail per product: DATEV Rechnungswesen and DATEV Unternehmen Online.

The client base is not only DATEV, which is the other half of the planning question. Clients who keep their own books tend to be in something lighter, and Lexware Office and sevdesk are the two that come up most often in that half. They reach your analysis in the same shape as the DATEV mandates, which is the point of doing it this way rather than per system. The full list of connected systems is worth a look against your own client base before anything is scoped.

Where our job ends

We deliver the numbers, the judgement stays in the practice

For most buyers this boundary is a matter of scope. Here it is a matter of professional responsibility, which makes it worth being blunt about.

What Maesn absorbs
  • One shape for every client system
  • Authorization per mandate
  • Each system's own vocabulary
  • Their yearly breaking changes
What stays yours
  • What the figures mean
  • Every filing and every signature
  • The advice built on top
  • Your professional obligations

Nothing here interprets a figure, prepares a return, takes a position or submits anything to an authority. That is not modesty about the product, it is the only arrangement that works: the responsibility for what a number means is regulated and personal, and it does not become shareable by putting an API underneath it. What is delivered is the client’s own accounting, in one shape, from wherever they keep it.

The practical consequence is about who in the practice owns this. It is usually not the person doing the analysis. Somebody has to hold the connections, the client authorisations and the job schedule, and in practices that build their own tooling that is the same role as on any other product and engineering side. Agreeing that split before the first mandate is connected is cheaper than agreeing it after the third one stops refreshing.

One more thing that belongs here rather than in a sales conversation. A practice that licenses a third-party product is buying somebody else’s judgement about which objects matter, and a practice that builds its own is buying data access and keeping that judgement. Both are served by the same connection, and the second is the case this page is written for, because the first one usually means the vendor is our customer instead. The pricing follows the connection rather than the calls, which matters more for a client base than for a single integration.

Tax advisors FAQ

Common questions

Which practices already run on this?

None that Maesn publishes. The customers named on this site are software products, several of them built for the tax profession rather than by it, and no practice appears among them. What carries this page is the documented route instead: the DATEV guides, the per-object field lists each vendor publishes, and the four workflows that are described endpoint by endpoint. If a named reference from a practice matters for your decision, ask for the current state of that directly rather than reading it off a page.

We already have everything in our Kanzlei-Rechnungswesen. What is missing?

The clients who do not book there. A practice's own system holds the mandates it books itself, and beside them sit the clients who keep their books in their own tool and hand over a result. Analysis across the whole client base has to reach both, and the second group is where the exports and the chasing live. That is the gap this closes: the same objects in the same shape whether a mandate is booked in your system or in the client's.

Does the client have to agree to this?

Yes, and that is a feature of the arrangement rather than an obstacle to it. Every connection is authorised per client, for their own system, and the practice sees what that authorisation covers. Nothing is read on the strength of the mandate relationship alone. For DATEV Rechnungswesen there is a second precondition worth knowing before the first client rather than during it: the export service has to be switched on in the DATEV account, and that runs through your customer success manager here.

We are building our own reporting tool. Does that rule us out?

It is the more common of the two cases. Practices either license a third-party product or build the thing their own way of working needs, and the second group buys data access rather than an application. Nothing on top of the connection is prescribed: the objects arrive in one shape and what you compute from them, present and sell is entirely your build.

How current is what we read?

It is fetched when you ask rather than held in a cache here, so a read reflects the client's system at that moment. Keeping a large client base fresh without re-reading all of it is the part that differs per system: some document a filter for what has changed since a timestamp and some do not, and where the filter is missing, a refresh costs a full read of the period. That is a design question for your job scheduling, and it is worth asking per system before it is assumed for all of them.

Where does client data end up?

In two places only, the client's system and yours. There is no third copy in between, because nothing that passes through is written down here beyond the fact that it moved. For a practice the follow-up question is usually the one a professional indemnity insurer asks rather than an engineer: who could read this if they wanted to. The answer is that the data does not rest anywhere it could be read from, and the certifications and hosting behind that statement are set out in full on the security page.

Can an AI agent read client data through this?

That is the case the fourth workflow is about, and the constraint is the interesting part rather than the capability. An agent reaching a client's ledger needs the same authorisation, the same scope and the same audit trail as any other caller, which is exactly what a governed connection provides and what an agent pointed at a spreadsheet export does not. Where a hosted component is out of the question, the MCP server is documented in a local variant.

Is any of this tax advice, or does it prepare a filing?

Neither. What arrives is the client's own accounting objects in one shape. No figure is interpreted, no return is prepared, no position is taken and nothing is submitted anywhere. The professional responsibility for what a number means and what is filed on the strength of it stays with the practice, which is where the professional regulations put it and where it belongs.
Related industries
Banks & Business LendersUnderwrite and monitor on data straight from the books.Learn moreB2B FintechPlatforms whose product depends on the general ledger.Learn moreEnterprisesMulti-entity groups whose own IT builds on the ledger.Learn more

Build once on the Unified API.

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

Book a demoRead the docs