Payment reconciliation that posts where their ledger lives
Your engine already knows which payment settles which invoice. What it does not know is whether this customer's system wants that as a two-sided journal entry or as a payment against a document it already holds. Maesn delivers both routes and the accounts each one needs.
- DEBITThe bank account it landed in
- CREDITThe receivable it settles
There is no contra-account field. The second side is a second line, and the guide expects you to name both.
One reconciled result, two incompatible destinations
Building the reconciliation engine is hard and bounded. Getting its output into the ledger is neither, because the ledger is a different one for every customer and they do not agree on what a settlement looks like.
The work your product does upstream is the part nobody else can do for you: settlement lag, bundled payouts, fees, currency, refunds. The output of all that is clean and simple, a set of bookings ready to post. Then a customer says they are on DATEV, or Twinfield, or that their Dutch entity runs Exact Online, and a bounded engineering problem turns into an open-ended one.
It is not the number of integrations that makes it open-ended, it is that they disagree about the object. A journal entry asks you to name both sides of the booking, which means knowing the customer's chart of accounts and deciding which account each side hits. A payment asks for less and for something different: one account, an amount, and the id of the invoice it settles, because the system already holds that invoice and applies the money to it. Those are different features in your product, not two adapters around one feature.
And the split is uneven in a way that matters when you plan. The route that reaches the most systems is also the one that asks the most of you, so a product that only implements the easier one reaches a handful of systems, and a product that only implements the harder one misses the ones that will not take it. The reads behind either route come from master data that has to line up first, which is its own documented use case.
One booking shape, and the accounts it has to reference
What a reconciled entry may carry is documented per system, and the fields that every system takes are exactly the ones that make an entry an entry.
The two fields on every system are the account and the side, which is the whole of double-entry bookkeeping and the reason a reconciled booking is portable at all. Everything past that is where systems differ, and the differences are knowable before you build: the same normalized objects deliver the chart of accounts, the tax rates and the journals your entry points at, and a tax rate frequently arrives without a rule for applying it, which is a decision you keep rather than one the connection makes.
Two things the entry carries deserve naming because they are easy to miss. It takes an accounting period, so a booking can land in the period it belongs to rather than the one it was sent in. And it takes a reversal flag, so a correction has a documented shape. Attachments work the same way: the request is multipart and a file can be tied to a specific line, which is how a bank statement ends up on the booking instead of in a folder. Where a system holds something the shared model has no field for, reaching past the model is documented, and the customer authorises all of it once.
What the connection does not do is decide the accounting. The guide asks you to specify the account and the contra account for each entry, and that is the right division: which account a fee hits, how a bundled payout splits, and what period it belongs to are questions about your customer's books that no integration layer is in a position to answer.
A batch of bookings posted the way each system takes them
A reconciliation run does not produce one booking, it produces a cycle of them. One system in particular is built for exactly that, and its route is different enough to plan for.
One entry per call, and the response tells you whether it posted. This is the route the field lists above describe, and the nine field lists on that endpoint all agree about it.
A list of entries in one call, and the answer is a task rather than a result. Its own guide sends you to GET /asyncTask to find out whether the batch was accepted.
DATEV Rechnungswesen has no entry on the single-booking endpoint's field list, which reads like missing support until you find its own guide. It posts through the batch route by design, which is also the shape a reconciliation run wants: a settlement cycle produces many entries at once, not one.
The batch route is the better fit for this use case and the reason is structural rather than a matter of convenience: a settlement cycle produces many entries at once, and posting them one call at a time turns a single business event into a queue you have to manage. Handing over a list and polling for the outcome is the shape the work already has. Building for that answer from the start is far cheaper than retrofitting it, because a write that returns a task and a write that returns a result need different error handling around them.
The practical consequence is a second code path, and it is worth pricing in early. Posting to DATEV Rechnungswesen means assembling a list, handing it over and matching a task id back against what you sent. Posting to Xero means a call per entry and an answer in the response. Same booking, two different pieces of software around it, and the difference is invisible until the first customer on the other system arrives.
The system this page is about, in a customer's own words
Rally replaced a direct DATEV integration with one API.
“Maesn completely transformed how we integrate with DATEV. What would have been a complex direct integration became a smooth, intuitive process thanks to their REST API and DATEV sandbox.”
Rally is this page's subject from the other side. The quote names DATEV and it names the sandbox, which is the part a team posting bookings cares about: a place to get the shape of an entry right before it lands in a customer's books. Their published account describes replacing a complex direct integration, and the section above is the concrete version of what that replaces. Systems like Business Central sit on the other side of the split, taking either route, and sevdesk takes only the payment, which is the distinction the first section is about.
Both routes and what they reference, counted per system
The two ways a reconciled result can land, then what a booking points at, counted from the per-system documentation.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Journal entries, writing | 10 | 11 | 8 |
| Payments, writing | 6 | 15 | 8 |
| Chart of accounts, reading | 19 | 8 | 2 |
| Tax rates, reading | 12 | 14 | 3 |
| Journals, reading | 5 | 15 | 9 |
| Dimensions, reading | 3 | 17 | 9 |
| Bank lines, reading | 0 | 21 | 8 |
Read the top two rows together rather than separately. They are nearly separate sets of systems, so adding them up describes nothing, and treating either as the number would overstate one and hide the other. The rows beneath are what an entry has to reference, and they thin out in the usual direction: accounts almost everywhere, tax rates on most of it, journals and dimensions on a handful.
The last row is the one this page is built around. Bank lines are readable on none of the connected systems, so nothing here compares a statement against open invoices. That is also why the receivable side and the payable side both stop at the document rather than at the bank, and why reading only what changed is how you keep the open items you match against current.
You reconcile, we post the result
This is the one page in the family where the boundary was already drawn correctly by the page it replaces, and the coverage is the reason it holds.
- Both documented posting routes
- The accounts, rates and journals
- Batch posting where it exists
- The attachment, on the entry
- What each payment settles
- Which account each side hits
- How a bundled payout splits
- When the booking is posted
Everything on the left is the connection: two routes into a ledger instead of one integration per accounting platform, the master data an entry has to reference under one set of field names, the batch route where a system offers it, and a file that travels with the booking. That is the part which otherwise grows with every customer who runs something new.
Everything on the right is your engine, and on this use case that is the substance. Which payment settles which invoice is a question about data we cannot see, since bank lines are not readable through any connected system. How a bundled payout splits, which account a fee belongs on, and when a cycle posts are decisions about your customer's books and your product's workflow.
Two things belong here because the page this replaces put them under the wrong heading. Posting a booking twice is prevented by your write happening once, not by a guarantee from us, and since no object has delete enabled, the fix for a double posting is a reversal rather than a removal. And the tax treatment of an entry stays with you: we deliver the rates the system publishes, in the form it publishes them. The lastModified filter is what keeps the accounts and rates you cached from drifting away from the ones your customer sees.
Matching a payment to an open item is the month-end work of financial teams, and it is the reason the two write routes matter to them at all.
Common questions
Does Maesn reconcile payments for us?
How does a reconciled result get into the ledger?
Why is there no contra-account field?
Can we post a whole settlement batch at once?
Can we attach the bank statement or the voucher?
What about cost centres on the booking?
Does Maesn map our categories to their accounts?
How do we avoid posting the same booking twice?
Can we reverse a booking that turned out wrong?
Which systems can we post reconciled bookings to?
Build once on the Unified API.
See how payment reconciliation works for your integration, or dive into the technical reference.