maesn
Use case

AI agents, enabled on the ledger they reason about

Agent-based products decide at runtime what to ask, which is what makes them useful and what makes their inputs load-bearing. Maesn gives your agent one shape for customers, invoices, bills, accounts and postings, from whichever accounting system each of your customers happens to keep.

Book a demoRead the docs
What your agent decides

Which cost this is, which period it belongs to, what the number means, how to phrase the answer.

reads it, does not guess it
What it must never invent
  • Which accounts exist
  • Which tax rates apply
  • Which dimensions exist
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

Your agent asks at runtime, the endpoint was fixed long before

An agent's advantage is that nobody decided in advance which question it would ask. The systems it asks were built on the opposite assumption.

Every list endpoint of the API, by what you may ask it
11
Nothing to narrow by
Line items, documents, projects, units
12
One question only
What changed since you last asked
13
More than that
Invoices, bills, open items, customers
And a sort order is rarer still: of the thirty-six endpoints, three accept one. Counted from the published parameter blocks in the API reference, leaving out paging, the two that select whose books to read, and the raw-data switch, because none of those decides which records come back.

This is the count behind a sentence the platform has always been open about. Filtering, ordering and paging are supported where the system underneath supports them, and what each endpoint accepts is published rather than implied. Nobody had added it up, and added up it says something specific about agent-based products: for most objects, the only question you can put on the wire is what has changed since you last asked. Being told instead of asking is rarer still, because an event only exists where the system underneath sends one, which on this market is a minority of them.

For a classic integration that is a nuisance you code around once. For an agent it is architectural, because the flexibility your product sells is exactly the thing the wire cannot carry. The way out is not a richer query language, it is a different division: fetch broadly through one model, hold what you fetched, and let the agent be flexible over that. The unified model is what makes the broad fetch affordable, since the same call and the same field names work on every system your customers use rather than one dialect at a time.

The second half of the problem is quieter and more expensive. A model asked to book something will produce an account number, a tax rate and a cost centre whether or not it has been told which ones exist, because producing a plausible answer is what it does. In a chat window a plausible answer is a bad answer. In an accounting system it is a posting.

How Maesn solves it

Every write recipe opens by reading the customer's own vocabulary

Not a rule we invented. Four of the sixteen documented recipes open with the same three reads before they describe a write at all, and two more open with two of them.

read firstOn all four of the recipes below
Which accounts exist

This customer's own chart of accounts, not a standard one

Which tax rates apply

The tax rates configured in that particular installation

Which dimensions exist

Cost centres, and whatever else their bookings point at

Then
Post an expense

One write, carrying the account, the rate and the dimension the reads returned.

Then
Post a booking

Opens with a fourth read the others do not: which journals a booking may go into.

Then
Settle a payable

Two writes rather than one: the bill itself, and the payment made against it.

Then
Settle a receivable

The invoice or a proposal to be reviewed, then the payment that settles it.

Read as a requirement it is unremarkable, because it is what correct bookkeeping has always needed: you post to an account that exists, at a rate that installation uses, against a dimension that customer actually keeps. Read as an instruction to an agent it is the whole design. The grounding read is the step that turns a model's proposal into something checkable, and it is the step a product under time pressure leaves out, because a hard-coded account number works on the first customer.

What a unified layer changes here is not that the step exists but that it is the same step everywhere. One call returns the chart of accounts whether your customer books in DATEV Rechnungswesen or in something else entirely, and the field names come back from one data model rather than from each vendor's vocabulary. So your product implements “learn this customer's books” once, and onboarding a customer on a system you have never seen is a connection rather than a project.

Which of your customers a call belongs to is settled underneath all of it, by the connection each of them authorised, so an agent never handles anybody's credentials and never reaches further than the person who granted the access could reach themselves.

What you get

A demanding client, and a connection that survives it

Agent-based products read more than form-based ones, and they read in bursts, because one user question can become a dozen lookups before an answer exists.

What an agent does
Asks for a lot at once

A single question can fan out into many reads, and they leave your backend together rather than politely spaced.

one at a time, per tenant
What reaches the system
A single file

Requests from one tenant reach the target system one after another, so a token refresh underneath them cannot be raced.

The behaviour on the right is documented for a specific reason rather than as a general promise. Several target systems break authentication when parallel requests arrive while a token is being refreshed, and re-authorisation is not a retry, it is your customer being asked to connect again. Sequencing per tenant is what keeps a burst from turning into that phone call. It does not do more than that: the target system's own rate limits still apply, and a refusal reaches you as its own category rather than as a generic failure.

The rest of the outcome is what you stop building. One shape for an invoice across every system in the directory, one authorisation flow, one place where a vendor's yearly breaking change is absorbed. For an agent-based product that is not a convenience, it is where the team goes: every week spent on somebody else's pagination is a week not spent on the model that is the reason customers bought the thing. Where a write cannot be processed immediately, it is handed to a task you poll for confirmation, so “did it land” stays an answerable question.

References

Products with a model at the core, already running on this

Published customer

Finto shipped a production-ready DATEV integration in days.

“Maesn enabled us to launch a production-ready DATEV integration within days, giving our AI structured financial data and our customers a smooth onboarding experience.”
Linus Boehm
CTO, Finto
Book a demo
4.8on G24.8 out of 5 stars on G2

Rally is the second, and its own site describes the shape well enough that we do not have to: receipts arrive from the field, Rally AI extracts the fields, matches payments and corrects errors, and what reaches the customer's ledger is already structured. Their CTO's account of getting there is on the Rally case study, and the part worth borrowing is the sequence rather than the adjective: the model does the judgement, the connection does the delivery, and neither is asked to do the other's job.

Both are what the industry view calls a further development of SaaS rather than a category beside it, which is the argument made for the vertical software market as a whole on the page for SaaS platforms. Neither of them publishes a number about this connection, and none is invented here.

Key facts

What an agent can reach, counted per object

The rows are the objects the documented recipes name, not a selection. Reach is per object rather than per system, so the thinnest row your workflow depends on is the one that decides your roadmap.

Across the 30+ connected systems
What you needTodayOn demandSystem cannot
Which accounts this customer has1982
Which tax rates that installation uses12143
Cost centres and other dimensions3179
Which journals a booking may go into5159
Invoices, to reason over13142
Bills, to reason over8174
Post a booking10118
Post an expense7193
Hand a proposal over for review10172
Derived from the per-system documentation at build time, never written by hand. The three columns are kept apart on purpose: what the docs mark as available on request is a marking, not a promise that it can be switched on, and stating it as one would be a claim nobody has made.

The shape of that table is the argument. The reads an agent needs in order to be grounded are not the widest rows, they are among the narrowest, and that is the opposite of what a roadmap assumes when it treats the grounding as setup and the write as the hard part. Knowing which of your customers' systems answers which of those rows is a week-one question, and it is answerable before you build, which is the only useful time to ask it. Where a single customer's installation carries a field the model does not, reaching past the model for that one field is a documented route rather than a fork of your integration.

The same discipline applies to what your agent reports back to a user. A write can succeed and still not do everything you asked, when a target system quietly ignores a field it does not carry, and the response says so through a warning next to the result. Surfacing that where a person can see it is the difference between an agent that is trusted and one that is merely confident.

Where our job ends

We make the data legible, the judgement stays your product

On this use case the boundary is unusually easy to state, because the thing on your side of it is the entire reason your customers chose you.

What Maesn absorbs
  • Auth and tokens per customer
  • One vocabulary for every object
  • The write shape each system expects
  • Their yearly breaking changes
What stays your product
  • What the model concludes
  • Which account a line belongs to
  • When a human has to approve
  • The record of what your agent did

The last row on the right is the one that surprises people, and it follows from the architecture rather than from a gap in it. Because nothing is stored on the way through, there is no copy of your customers' books here and equally no transcript of what your agent proposed. What Maesn holds is that a call happened, to which system, under which customer's connection, and when. The reasoning, the prompt, the version of the model and the person who approved it are yours to keep, and for an agent acting on financial data they are the half an auditor will actually ask about. The other half, how the transfer itself is protected and certified, is the same posture the rest of the platform runs on rather than something this connection weakens.

The row above it is the same principle one level down. The documentation puts categorisation logic in your application, and it has to sit there: nothing shared could know that one of your customers books a fuel receipt against a different account than the next one does. To settle it once, for everybody, would be to choose on their behalf how their books are kept, which is a decision belonging to them and their accountant. Failures divide along the same line, and which side a rejection came from is the first thing an agent's handler should branch on.

Where this shows up in the day-to-day is the engineering roadmap, which is why product and engineering teams are usually the ones who bring this connection in, and the reason they give is the same one every time: the integrations were never the product. If your agent is meant to work through an assistant a customer already uses rather than only through your own interface, the protocol side of that is the MCP server, which runs on this same API.

AI Agents FAQ

Common questions

How is this different from your MCP server?

By who is holding the thing. The MCP server is for connecting an assistant somebody else built, such as Claude, to the systems: you configure a client and ask questions in a chat window. This page is for a company whose own product is the agent, where the calls come from your backend on behalf of each of your customers and nobody opens a chat window at all. The same Unified API is underneath both, which is why coverage and the security model read the same on either page.

What does an agent have to read before it can post anything?

The customer's own vocabulary, and the documented recipes are explicit about it: which accounts exist, which tax rates apply and which dimensions are booked against, before any write is described. Those are the values a model will otherwise improvise, and an improvised account number is the failure mode nobody notices until a reconciliation. Measured across the twenty-nine connected systems, accounts are readable today on nineteen, tax rates on twelve and dimensions on three, with most of the remainder marked available on request rather than unsupported.

Can we query the data the way our agent asks for it?

Not on the wire, and it is worth knowing the shape of that before you design around it. Of the thirty-six list endpoints, eleven publish nothing to narrow by, twelve publish only a way to ask what changed since your last call, and three accept a sort order. So the flexible part belongs in your product: fetch through one model, hold what you fetched, and let the agent be flexible over that rather than over each vendor's query surface.

How does an agent get access to our customer's accounting system?

Your customer authorises the connection once, to the system their bookkeeping already lives in, and every later call runs under that authorisation rather than under a central service account of yours. Which customer, and which of their companies, a call belongs to is settled by the account key on the request. Nothing is re-implemented centrally, so a restriction that exists in their system still exists through this connection.

Do you store our customers' financial data, or train anything on it?

Neither, and the second follows from the first. Nothing your customers' books contain comes to rest here: the call reaches the system they authorised, the answer is put into one shape on the way out, and that is the end of it. There is therefore no corpus to train on even in principle. For an AI product that removes the question a compliance review usually stops at, and it has a consequence worth designing for on day one, which is that whatever you may need to show later has to be written down on your side.

Can we prove afterwards what our agent did?

In part. The trail on our side answers where and when, not what: which endpoint was called, against which target system, under which of your customers' connections, at what moment. The response body is not in it, because it is never kept. A response can also carry warnings, for instance that a field is not used by the target system, which is how a write that succeeded but did not do everything you asked stops being a silent difference. Everything else, what your agent proposed and on what basis, exists only where you record it, and that is the half a regulator will ask you about.

What happens when the model proposes something the system rejects?

It comes back as a categorised failure rather than as one vendor's prose, and the useful distinction for an agent is where it failed: input Maesn rejected before the call left, or the target system's own refusal passed back untouched. The first says your agent produced something malformed, the second says the ledger would not take it. Those are different bugs and they need different handling, which is the whole subject of the error handling page.

Which agent workflows does this actually cover?

The ones the documented recipes describe, which is where the object sets on this page come from rather than from a wish list. A cost classification agent lands on expenses or on journal entries, both of which are documented writes, at seven and ten systems today. An agent that works on the open position reads invoices and bills and hands a proposal over for review, which is documented at ten. None of them hands back a finished statement, because no connection does: what arrives is postings, and a statement is something your product adds up from them.

Is a write confirmed, or is it fire and forget?

Confirmed. Depending on the target system a write is processed directly or handed to an asynchronous task you poll, and either way there is a point at which you know it landed. That matters more for an agent than for a form, because a form only submits what a person already approved, while an agent can be wrong in a way that is worth catching before anybody reads a report built on it. Where the writing happens on a schedule rather than on somebody's click, most teams put a review queue in front of it and let the model fill the queue, which keeps the speed and leaves the accountability with a person.

How many systems does one build reach?

Your product is built against one model and reaches the twenty-nine systems in the integration directory, which is the answer to "our customers all book somewhere else". The honest half is that reach is per object rather than per system, so the number that decides your roadmap is the thinnest row your workflow depends on, not the widest. That is what the table above is for, and it is derived from the documentation rather than restated by hand.
Related use cases
Expense ManagementPush expenses into the accounting structure in place.Learn moreFinancial Analysis & ForecastingRead the ledger, invoices and accounts a forecast needs.Learn morePayment ReconciliationDeliver reconciled bookings into any accounting system.Learn more

Build once on the Unified API.

See how AI agents enablement works for your integration, or dive into the technical reference.

Book a demoRead the docs