Use case

Bank feeds that land in the books, not in a file

A bank movement leaves the bank fully structured and reaches the accounting system as something somebody typed. Maesn writes it straight into the system your customer keeps, in the shape that system accepts.

Book a demo Read the docs

One movement, as the bank has it

Amount: −1.284,00 EUR
Description: Rechnung 2026-0417
Value date: 12.08.2026
Counterparty: not resolved yet

one write, four routes

In your customer's ledger

An entry their accountant can see, assign and post, on seventeen of the twenty-nine connected systems.

Trusted by winning software teams

4.8on G2

The problem

The movement is structured at the bank and unstructured by the time it books

Nobody loses the data. It is taken apart in the middle, by a step that only exists because the two systems were never connected to each other.

As the bank has it

Amount: − 1.284,00 EUR
Description: Rechnung 2026-0417
Value date: 12.08.2026
Reference: EREF+2026-0417

After it is retyped

Amount: − 1.284,00 EUR
Description: Rechnung 0417
Value date: not carried over
Reference: not carried over

Download
Hand over
Retype
Book

A statement export usually keeps more than a retyped entry does. Either way the two fields an automatic assignment would run on are the ones with the furthest to travel.

The delay is what the end customer complains about. A movement that settled on Monday shows up in the books when somebody gets round to the export, and until then the accounts are a week behind the bank. That gap is not a property of accounting. It is the length of somebody's to-do list.

The more expensive cost is that the detour is per customer. A provider moving transaction data does not get to choose which accounting system the movement has to end up in: that was decided years ago by whoever set up the books, and across a customer base it is a dozen different answers. Building into each of them directly means a separate integration per system, each with its own idea of what a movement is called and which fields it must carry, and each of them ageing on its own schedule.

And the two things that would make the movement useful on arrival are the first to go. The bank knows the value date and the payment reference; a statement export usually keeps them and a retyped entry usually does not. Those are exactly the two fields an assignment would run on later, which is why so much assignment ends up being done by eye.

How Maesn solves it

Four documented routes into the ledger, and they differ by what you must already know

A bank movement can enter an accounting system in more than one shape. Which shapes a given system accepts is documented per system, and so is what each shape demands before it will take the record.

What it needs decided first

What that means in the field list

Systems

Nothing beyond the movementPOST /transactionsAmount and description are documented on all four. A counterparty is required on one of them and cannot even be sent on two.Systems4
Who it belongs toPOST /bookingProposalsA counterparty field on all ten, and required on seven of them. The three that leave it optional are DATEV Unternehmen Online, Lexware Office, sevdesk.Systems10
Which document it settlesPOST /paymentsThe narrower route by design: a payment is booked against something that was already issued.Systems6
Which account, and which sidePOST /journalEntriesThe account is required on eight of the nine documented lists. At this point the booking decision is already made.Systems10

Counted across the twenty-nine connected systems, and a system can appear on more than one row. Together the four routes reach seventeen.

Read the last column on its own and the four routes look like four sizes of the same thing. They are not. Every system that accepts an open transaction accepts a booking proposal or a journal entry as well, so that route adds zero systems to the total and choosing it buys no coverage at all. What it buys is the one thing the other three will not do: take a movement that nobody has assigned yet.

That turns the design question around. It is not which route covers the most systems, because on that measure they end in the same place. It is how much of the movement your product is willing to resolve before it sends. Resolve nothing and you are writing to the systems that accept an unassigned record. Resolve the counterparty and the widest route opens up, at the price of having to be right about it. Resolve the account and the side and you are no longer posting a feed, you are posting a booking, and the correction path if you were wrong belongs to your customer's accountant rather than to you. The shapes themselves are the same on every system, which is what the common data model is for, and the access behind them is granted once per customer through one authorisation flow.

What you cannot do

Read a bank movement back out

There is no GET /transactions anywhere in the reference. Across 208 documentation URLs the write endpoint is the only transactions endpoint there is, so the movement goes in and never comes back.

What you can do instead

Read the postings, and pick out the bank account

Journal entries are readable on ten systems, and the account sits on the line inside them, not on the entry.

The two things to check before you plan on it

There is no account filter in the request. The filter object on the read carries a modification date and nothing else, and two of the documented systems publish no filter at all. Selecting the bank account happens in your product.
three of the nine documented responses carry no lines at all (Exact Online, Fortnox, odoo). The account a movement belongs to lives on that line, so on those three a bank movement cannot be told apart from any other posting.

The direction matters more here than on most use cases, because the obvious mental model is wrong. A feed sounds like a stream you can also observe, and this one is not: there is no read endpoint for transactions at all, so nothing you write comes back through the same door. What you can read is the ledger, and a bank movement in the ledger is a posting line pointing at a bank account.

Two consequences follow, and both belong in a build plan rather than in a surprise later. Selecting one bank account is work your product does after the read rather than a parameter it sends, so how much you read and how often is your decision; paginated, filterable reads and the jobs some systems hand back instead are what make that decision cheap. And where a response carries no lines, the movement is not there to be found, which is a per-system fact to check during onboarding rather than a rule you can apply once. What a partial or refused write looks like on the way in is unified error handling, and the record of what was sent when a customer queries a booking is logging and monitoring.

What you get

One write per movement, and the right shape chosen for you

The value is not that a bank movement can be posted. It is that which of the four shapes a given customer's system takes stops being your problem.

17take a bank movement

through at least one of the four documented routes

10accept exactly one shape

so there is a right answer per system, and only one

7leave you a choice

and even there the field lists differ per route

Counted across the twenty-nine connected systems, from the same per-system documentation as the table above.

Building this directly means finding out, per system, which shape it accepts and what that shape insists on, and then keeping up when a vendor changes its mind. For ten of the seventeen there is exactly one right answer, so the cost of guessing is not a degraded feed but a rejected write. That is the work this connection absorbs: your product sends a movement once, in one vocabulary, and which endpoint it becomes is decided underneath.

What that changes in practice is when the entry exists rather than whether it can. A movement can reach the books on the day it settles instead of on the day somebody remembers the export, and the person who assigns it keeps working where they already do that. It also changes what your roadmap has to carry: one integration to maintain instead of one per accounting system across a customer base you do not control.

Key facts

What arrives with the movement, field by field

On the route that accepts an unassigned movement, this is what each of the four systems documents. Read it as the ceiling rather than the plan.

On the open-transaction route: DATEV Unternehmen Online, Exact Online, Lexware Office, sevdesk

amountDocumented on4The only two fields on all four
descriptionDocumented on460 characters on DATEV Unternehmen Online
bookingDateDocumented on3The date the ledger books it
accountIdDocumented on3DATEV Unternehmen Online names it accountNumber instead
valueDateDocumented on2The date the bank settled it
referenceDocumented on2What an automatic assignment would match on
filesDocumented on1The receipt as a file, on DATEV Unternehmen Online

Out of the four systems that document this route, read from their own field lists. Only Lexware Office documents both dates, so on the others the difference between when the bank settled a movement and when the ledger books it is a decision your product makes rather than data it carries.

The two fields that always arrive are the amount and a line of text. Everything that would let a machine decide what the movement belongs to is thinner than that: the bank reference on two systems, the value date on two, the receipt as a file on one. A product that plans to assign movements automatically on the reference is planning for a subset, and it is better to know which subset during onboarding than after the first customer goes live.

The date is the one worth reading twice, because the split runs exactly along the seam between the two worlds. The bank knows when it settled; the ledger wants to know when to book it. Three systems document the booking date, two the value date, and only one documents both. On the rest, the difference is not missing data so much as a decision your product has to make and be consistent about, and it is the kind of inconsistency that surfaces months later as a reconciliation that will not close. Keeping the counterparty behind a movement aligned with what the accounting system already holds is customer and supplier data sync.

Where this sits in a build is usually the harder question, and it is answered better by teams who have already done it than by a field table. How other products sequenced the write against the rest of their integration is written up in the case studies.

Coverage

Every object a feed touches, counted per system

Taken from the per-system documentation rather than from a summary, and the last row is part of the answer rather than an omission.

Across the 30+ connected systems

What you need	Today	On demand	System cannot
Booking proposals, writing	10	17	2
Postings, writing	10	11	8
Payments, writing	6	15	8
Open transactions, writing	4	18	7
Postings, reading	10	12	7
Bank accounts, as master data	3	19	7
Movements, reading back	0	21	8

The first four rows are the four ways in, and a system can appear on more than one of them. Below them sits what can be read back: the postings, and the bank accounts as master data. The last row is the one to read hardest, because it stays at zero: movements cannot be read through this connection at all, which is why nothing on this page offers to show you a statement.

The distance between the write rows and the read rows is what makes this a one-way job. Writing is well covered because every accounting system has to let something in, and each of them has an opinion about what that something is called. Reading is thin because a bank movement is not an object in this model at all: it is a posting, or a proposal, or a payment, depending on how it got there. That is also why two pages can share endpoints and still count differently: the rows they need are not the same rows.

One caution about vocabulary. The object called Transaction in the documentation is a catch-all for records that do not fit the other models, not a bank movement by definition. It is the right container for one, and the request example is a card payment, but the name is broader than the use case and nothing here should be read as a statement feed. The systems a European provider meets most often on these routes are worth checking individually before scoping: DATEV Unternehmen Online, Lexware Office, sevdesk and Exact Online. What the connection keeps, and for how long, is set out on the security page.

Where the line runs

We deliver the movement into the ledger, you decide what it means

A feed is one half of a job. The other half is assignment, and it belongs to the side that knows the business behind the movement.

Maesn delivers

The write, in each system's shape
One vocabulary for the record
The postings, read back
The per-system field limits

Your product owns

Where the movements come from
Which account they belong to
How they are matched, if at all
When and how often you send

Maesn is not the source of the bank data and does not connect to any bank. Whether the movements arrive from a licence of your own, an account-information provider, a card programme or a customer upload is your side of the line, and it is the side your customers are paying you for. What ends at our boundary is the other one: writing that movement into whichever accounting system a given customer keeps, without you building and maintaining a connection per system.

And there is no matching engine anywhere in this. Deciding that a movement settles a particular invoice, and writing that decision back so the open item closes, is a different job with a different page: payment reconciliation. This one stops at delivery, deliberately, because a feed that guesses is worse than a feed that arrives unassigned next to the customer's own tooling. Reading whole ledgers to understand a company rather than to place one movement is financial analysis and forecasting, and the teams who live with the result of all three are financial teams. Where an agent rather than your own code drives the write, the same routes are exposed through the MCP server, and the fields a single installation invented are reachable without waiting for the shared model to grow.

Bank feeds FAQ

Common questions

Which systems can we post bank movements into?

seventeen of the twenty-nine connected systems accept a bank movement through at least one documented route. Which route works depends on the system rather than on your preference: the open-transaction endpoint is documented on four of them (DATEV Unternehmen Online, Exact Online, Lexware Office, sevdesk), booking proposals on ten, journal entries on ten and payments on six. Most systems offer exactly one of the four, so the practical question during onboarding is not whether a customer's system is covered but which shape it wants.

Does picking a different route reach more systems?

No, and that is worth knowing before the build. Every system that accepts an open transaction accepts a booking proposal or a journal entry as well, so that route adds zero systems to the total and buys no coverage at all. What it buys is that it accepts a movement nobody has assigned yet. The other routes reach the same seventeen in total and each want something decided first: who the counterparty is, which document is being settled, or which account and which side. The choice is about what your product knows, never about how far it gets.

Do we have to work out the counterparty before sending?

On most routes, yes. The booking-proposal route carries a counterparty field on all ten systems and requires it on seven of them. The open-transaction route is the exception and the reason this use case exists separately: on two of its four systems a counterparty cannot even be sent, so the movement lands unassigned and the accountant assigns it where they already do that work.

Can we read bank movements back out again?

No. There is no read endpoint for transactions anywhere in the reference, so a movement written through this connection does not come back through it. What is readable is the postings: journal entries on ten systems, with the account on the line inside the entry. Bank accounts themselves are readable as master data on three systems (bexio, Lexware Office, sevdesk), which is the account list rather than its movements.

Can we ask for only the movements on one bank account?

Not in the request. The filter object on the journal-entry read carries a modification date and nothing else, and two of the documented systems publish no filter at all. The account sits on the individual posting line, so selecting one bank account means reading what changed and picking the lines out on your side. That is a design decision worth making early, because it sets how much you read and how often.

Will every system show us the posting lines?

No, and this is the sharpest limit on this page. Of the nine systems that document their journal-entry response field by field, six return the line items and three do not: Exact Online, Fortnox, odoo. The account a movement belongs to lives on that line. Where the lines are absent, a bank movement cannot be identified in the postings at all, whatever the headline coverage number suggests.

Does the bank reference and the value date arrive?

Less often than the amount does. On the open-transaction route the amount and the description are documented on all four systems, the booking date on three, and the bank reference and the value date on two each. Only Lexware Office documents both dates, so everywhere else the difference between when the bank settled a movement and when the ledger books it is something your product decides rather than something the record carries. A feed that matches on the bank reference is a feed built for two systems.

How is this different from your payment reconciliation use case?

By whether the assignment has already happened. Payment reconciliation is about a payment that you have already matched to an invoice, and about writing that match back so the open item closes. Bank feeds is about getting the movement into the books at all, before anyone knows what it belongs to. They share endpoints and answer opposite halves of the same day's work, and a product that does both usually builds them as two flows.

Do you connect to the bank for us?

No. Where the movements come from is your side: your own banking licence, an account-information provider, a card programme or a customer upload. Maesn is the other end, the accounting and ERP systems your customers keep, and the value is that you write to one shape instead of one integration per system your customers happen to use.

Is anything stored on the way through?

No. The movement is not warehoused here. It is normalised, written to the system your customer authorised, and gone. What persists afterwards lives in their books, under their control and their retention rules, which is where an auditor expects to find it.

Related use cases

Accounts PayablePost bills and payments into your customers' ledger.Learn more Accounts ReceivableIssue, track and settle receivables in every system.Learn more Company ConsolidationConsolidate entities that each run their own system.Learn more

Build once on the Unified API.

See how bank feeds works for your integration, or dive into the technical reference.

Book a demo Read the docs