Sync expenses in the shape each system requires
Your product knows what was spent, by whom and on what. What it does not know is which of three field names this customer's system uses for the ledger account, or whether the line has to carry the net amount or the gross. Maesn delivers that, then posts the expense.
- accountId4 systems
- accountNumber2 systems
- accountCode1 system
Across the connected systems, 7 accept an expense you write. They agree on what the line needs and not on what to call it.
One expense object, seven different contracts
Writing an expense is a single call on every system that supports it. What that call has to contain is different on all seven, and the differences are not cosmetic.
The object itself is simple and it is the same everywhere. A header says when the money moved and in which currency; a line says which ledger account the spend belongs to, how much it was, and at what tax rate. Every system that accepts an expense wants exactly that much. No two of them want it in the same words.
The account is the visible case. All seven require the line to name one, and between them they call it accountId, accountNumber and accountCode. That costs you a mapping table and nothing more. The amount is the one that goes wrong quietly, because both figures are perfectly valid numbers and only one of them is the one that system asked for. A line sent gross where the net was required is not rejected, it is booked, and it is booked wrong by exactly the tax. That the tax rate is itself often published without any rule for applying it is the second half of the same problem.
On top of the shared shape, every one of the seven adds something none of the others asks for. QuickBooks wants a payment type, and the account on the header has to be of the matching kind. Xero wants to know whether the document is an expense or a refund, and it wants either a supplier or a customer rather than neither. Exact Online and Twinfield want a journal code. Lexware Office wants a document number and a tax rate percentage on every single line, which is worth pairing with a second fact about that system: it is the only one of the seven whose tax-rate read is marked on demand rather than supported today. None of these is unreasonable. Together they are the reason an expense integration is rarely finished after the first system.
One connection for the accounts, the rates and the dimensions
Everything an expense has to reference comes back in one shape from every connected system, which is what lets your users map their spend onto their own accounting setup once instead of once per vendor.
Of the 29 connected systems, seven accept an expense and ten accept a journal entry, which is the route the guide mentions in its closing line. Only five accept both, so this is not a fallback for the weaker systems: DATEV Unternehmen Online and Lexware Office take an expense and no journal entry, while five others take a journal entry and no expense. Counting either route, twelve systems can receive spend from your product today.
The chart of accounts is the load-bearing read of this use case, and it is also the strongest one: the same normalized object is readable on nineteen systems, and on every single system that accepts an expense. What varies is how much each one puts in it. The field the guide suggests grouping by, so that a user sees expense accounts rather than a flat list of hundreds, appears in seven of those nineteen documented field lists, and the parent reference that would let you draw the ledger hierarchy appears in two. Neither gap stops the use case. Both decide how good the account picker in your product can be for a given customer, which is exactly the kind of thing worth knowing before a design review rather than after one.
The rest of the chain is ordinary once the connection exists. Your customer authorizes it once through one flow whichever system they run, tax rates and suppliers arrive as the same objects everywhere, and reading only what changed since the last run is how a cached chart of accounts stays honest while your users edit theirs. Where a system holds something the shared model has no field for, reaching past the model is documented rather than improvised.
What a connection cannot do is invent the data. Dimensions are the honest example. Three systems publish a readable list of them today and most of the rest carry an on demand marking in their own documentation, which is a marking and not a promise. Separately, exactly two systems document a dimension field on the expense line itself, and they are not the same two. So a cost-centre feature is buildable, and it is buildable for named systems rather than in general, which is a much better sentence to put in front of a customer than an assurance that everything is supported.
The expense lands where their accountant already looks
The result of all of this is unglamorous and it is the point: spend that occurred in your product appears in your customer's ledger, on their account, at their rate, without anybody exporting a file. The clearest way to show what that takes is one system where the ordinary words do not apply.
Two fields, and type takes one of three values: CASH, ACCOUNTS_RECEIVABLE, ACCOUNTS_PAYABLE. No number, no class, no balance. This is a list of ledger folders rather than a chart of accounts, which is what the guide means when it notes in passing that for DATEV the endpoint only provides account ledger names.
The folder name goes straight back in, and it has to be one of type CASH. The response is a task id rather than a booking, so GET /asyncTask is where you learn whether it landed. The synchronous endpoint still lists this system and marks it deprecated, pointing here.
DATEV Unternehmen Online does not hand out a chart of accounts at all. What comes back is a short list of ledger folders with a type, and the write wants one of those names back, of the cash kind. A product built on the assumption that every system returns numbered accounts has nothing to show its user here. A product built on what each system actually returns has a list its user recognises and a posting that lands, which is the same difference the DATEV integration makes on every other use case too.
The second half of that panel is the part most integrations discover late. This write is asynchronous: the response is a task id, and a separate call tells you whether the booking landed. Handling that properly means your user hears about a failure minutes later instead of never, and it is far cheaper to build for at the start than to retrofit onto code that assumed an answer would arrive with the request.
Two smaller things belong to the outcome as well. The receipt travels with the expense on six of the seven systems, because the write is a multipart request and takes the file alongside the data, so the document your user photographed sits where their accountant expects it rather than in a folder somebody has to reconcile later. And the trigger stays yours: whether an expense syncs the moment it is approved, in a nightly run, or only when somebody presses a button is a decision about the workflow your users already have, not about the connection.
Expense management, embedded in their customers' accounting
Findity puts expense sync inside their partners' products.
“Maesn has helped us build integrations with accounting systems, allowing us to focus on other priorities in our roadmap. We are especially pleased with the support we have received whenever we needed extended functionality in an integration that Maesn has arranged for us.”
Findity builds expense management as a white-label and API product, which means their integrations are not theirs alone: every partner who embeds them inherits whatever accounting systems Findity can reach. That is this use case at its most demanding, and the part of the quote worth reading twice is the second sentence, about extended functionality being arranged when an integration needed more than it had. Systems like Lexware Office, Xero and QuickBooks all accept an expense and disagree about nearly every field of it, which is the work that gets absorbed here. The customers who have a published case study are a different set, and this one is a quote rather than a study.
Every step of the sync, counted per system
Both write routes first, then everything the expense has to reference, counted from the per-system documentation.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Expenses, writing | 7 | 19 | 3 |
| Journal entries, writing | 10 | 11 | 8 |
| Chart of accounts, reading | 19 | 8 | 2 |
| Suppliers, reading | 19 | 2 | 8 |
| Suppliers, writing | 14 | 4 | 11 |
| Tax rates, reading | 12 | 14 | 3 |
| Dimensions, reading | 3 | 17 | 9 |
The table answers the question that actually decides feasibility, which is not whether expense sync works but how much of it works for the systems your own customers run. Read from the top down it also explains the shape of the guide: the write is narrow, the chart of accounts behind it is wide, and everything that makes a posting more specific gets thinner as it gets more specific.
One row is worth a second look for a reason that is not its size. Journal entries reach more systems than expenses do, and the documentation mentions that route almost in passing, as the simpler way to post spend. For a product whose users only need the amount in the right account, and not an expense document with a supplier and a receipt attached to it, that route is available on systems this one cannot reach. Suppliers are the comfortable rows here, and where they need creating rather than only reading, that is its own documented use case.
We deliver the structure, you own the categorization
On this use case the boundary is drawn by the documentation itself, which spends its longest step describing decisions it explicitly leaves to your product.
- Accounts, rates and dimensions
- One shape on every system
- The expense, written back
- The receipt, with the booking
- The account each expense uses
- The rules your users configure
- When the sync happens
- What counts as an expense
Everything on the left is the connection: the customer's real accounting structure delivered under the same names whichever system they run, and a write that lands as a booking rather than as a file somebody imports. That is the part which would otherwise be one integration per accounting platform, each with its own idea of what an account identifier is.
Everything on the right is your product, and here that is more than usual. The documentation devotes its longest step to categorization and then hands the whole thing over: a single default account for the simple case, conditional rules for the harder one, categorization at the moment of sync, and users overriding whatever was configured. It says the business logic depends on your application, and it is right to. What an expense means, which account it belongs on and who may change that are product decisions that sit close to what your users are actually paying you for.
One thing belongs here because the page it replaces put it in the headline. Maesn does not make spend tax compliant. We deliver the rates a system publishes and write back what your product assembled, and the accounting system it lands in is where the local rules apply, exactly as they did before. Where the spend reaches your users as a supplier invoice rather than as a card transaction, posting bills and their payments is the neighbouring use case with its own endpoints, and the lastModified filter is what keeps the accounts and rates you cached from drifting away from the ones your users see.
An expense that arrives already coded is what stops being rekeyed by financial teams.
Common questions
What does it take to sync an expense into a customer's accounting system?
Which systems accept an expense today?
Why does the required amount differ per system?
Does Maesn categorize the expenses?
Can we attach the receipt?
What about cost centres and departments?
Do we have to create the supplier first?
Is a synced expense tax compliant?
What happens when a posting takes longer than a request?
What if a system needs a field the shared model does not carry?
Build once on the Unified API.
See how expense sync works for your integration, or dive into the technical reference.