maesn
By industry

Banks and lenders underwrite on an export the borrower requested

Universal banks, savings and cooperative institutions, consumer lenders and lending fintechs all assess the same thing: whether a company's books support the credit. Maesn reads those books directly, once the borrower has said yes.

Book a demoRead the docs
The documented routeDATEV Rechnungswesen
the guide's own words
“the data you always dreamed of retrieving from the API instead of CSV exports”
  • GL accountsGET /accounts
  • Fiscal yearsGET /fiscalYears
  • Booking dataGET /journalEntries
  • Payment termsGET /paymentTerms
  • Sums and balancesGET /trialBalance

Five calls, one authorisation. The borrower needs the DATEV service for exporting accounting data switched on, which the guide states as its own precondition.

Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
4.8on G24.8 out of 5 stars on G2
The problem

The credit file waits on a document that three parties have to pass along

Underwriting a company means reading its accounting. Getting hold of that accounting is a chain of five steps across three parties, and the chain does not run once.

How the numbers reach a credit file today
three parties, five steps
  1. The lender
    asks for annual figures
  2. The borrower
    asks their tax advisor
  3. The advisor
    prepares the export
  4. The borrower
    forwards the documents
  5. The lender
    reads them back out
And again at least once a year, for every year the loan runs. The borrower has to remember, the advisor has to be asked, and the analysis starts over.
The chain as lenders describe it. The documentation describes the other end of the same thing when it offers the data “instead of CSV exports”.

Each station in that chain is reasonable on its own. The lender needs official figures. The borrower does not produce them, their tax advisor does. The advisor has other clients and a queue. The documents arrive as a PDF, which was an improvement on paper, and then have to be turned back into numbers with character recognition and a model, which takes time and is not exact. None of the parties is being difficult, and the decision still sits behind all of it.

The part that costs the most is the part nobody plans for: it repeats. A five-year facility means the same round trip at least five times, because the covenant review wants current statements. Every one of those is a reminder to the borrower, a request to an advisor, an upload and another read-out. Lenders describe the renewal cycle as more irritating than the original application, and the reason is that the original at least had a deal attached to it.

What makes this worth fixing rather than optimising is where the data already is. The advisor is not authoring those numbers, they are exporting them from an accounting system that holds far more than the summary. The documented route into that system describes its own purpose as retrieving the data from the API instead of from CSV exports, which is the same sentence as the one above from the other end.

How Maesn solves it

Sums and balances at two systems, the bookings behind them at six

A connection is only worth as much as what it returns, so the useful question is not which systems can be connected but which of them hand over enough to compute a position from. Read down the four steps and the answer narrows in a way the object-level tables do not show.

  1. 30+Connected accounting systemsThe number the figures below are measured against.
  2. 11Document a readable journalBookings can be fetched at all. This is the number the per-system coverage tables report, and it is where most planning stops.
  3. 6Return the lines, with an account and an amountOf the nine whose field list the reference publishes, three return the journal header alone: an id, a description, a number and a date. Nothing to compute a position from.bexio, Business Central, DATEV Rechnungswesen, Dinero, Sage Active and Xero
  4. 2Return sums and balances ready-madeThe aggregate itself, without you adding up a ledger, though both require a fiscal year start date on the request before they will answer. One of the two also documents monthly values; the other a single balance.DATEV Rechnungswesen and Sage Active

Counts for the first two rows come from the generated per-system matrix, the third from the field lists the endpoint reference publishes. The two sources name the same systems for sums and balances; for the journal they do not, and neither is treated as the whole truth here.

The turn in the middle of that ladder is the one to plan around, and it runs against intuition: the summary is rarer than the detail. Sums and balances arrive ready-made at two systems. The journal lines that a set of sums and balances is the total of arrive at six. A product built to require the aggregate endpoint therefore reaches a third as many borrowers as one that can add up debits and credits itself, and adding up debits and credits is not the hard part of underwriting.

The step below it is the one that is easy to get wrong from a coverage table alone. Three of the systems that document a readable journal return the header only, an identifier, a description, a number and a date. There is no account on it and no amount. In a per-object view those three are indistinguishable from the six that return everything, so the ladder above names its six rather than only counting them. The same distinction decided the shape of the travel page for the opposite direction of travel, on the way into a ledger rather than out of one.

What does not change between systems is the shape the data arrives in. Accounts, journal entries, fiscal years and terms come back under one data model rather than in each vendor's own vocabulary, which is what makes a second target system a connection instead of a second parser. Where a borrower's installation carries a field the shared schema has no place for, reaching past the model returns it without a fork, and which borrower and which of their companies a call belongs to is settled by one authentication layer.

What you get

One authorisation at application time, and every review after it

A lending relationship has two data moments rather than one: the decision at the start, and the monitoring that runs for the whole term. The second is where a connection changes more than the first.

Asking a system what changed, across the six that return journal lines
4document a delta filter
Business Central, Dinero, Sage Active and Xero
Ask for what moved since the last look, on whatever cadence a review runs.
2do not
bexio and DATEV Rechnungswesen
A refresh reads the period again and compares on your side.
Worth reading against the tiers above: the system that carries the initial decision most completely is in the right-hand column, so the review phase and the decision phase are not automatically the same build.

At the decision, the change is a step that disappears. The borrower authorises access inside your application flow, and the reads happen against their live ledger rather than against a document somebody assembled. Nothing has to be requested, chased or converted back into figures, and the analysis your team already runs gets more to work with than a statement carries.

In the monitoring phase the change is a different one: the borrower stops being involved. A quarterly or monthly review reads the current position without a reminder, an advisor or an upload, which removes the part of covenant monitoring that makes lenders postpone it. That is also where the second use of the same connection appears. A borrower whose bookings show recurring investment is a borrower with a next requirement, and a lender reading the ledger monthly sees it before the borrower asks anywhere else. The step-by-step version of the assessment itself, object by object, is the underwriting use case, which this page hands the mechanics to rather than restating them, and reading a ledger for analysis covers the reporting side of the same connection.

One limit belongs in the same breath as that. Continuous monitoring is something you build on these endpoints, not something Maesn runs for you: there is no subscription, no alert and no threshold in what we deliver. Where a target system emits events, webhooks carry a normalised payload and save the polling, and where it does not, a scheduled read is the mechanism. How that behaves once a portfolio rather than a borrower is being read is a question of filtering and paging, which is worth reading before the first thousand accounts.

Key facts

The tax advisor's own system, and what it takes to reach it

The chain in the problem section ends with an advisor exporting from a system. This is the API into that system, which is why it carries this industry rather than a customer list does.

DATEV Rechnungswesen, the one documented underwriting route
exclusive early access
Sums and balances, with monthly values

The only trial balance documented with monthly values rather than one closing figure.

The journal, with its lines

Account, amount and debit or credit on every line, plus a marker that flags a correction.

Fiscal years and payment terms

The fiscal periods the figures belong in, and the payment terms behind the receivables.

What has to be true first
  • The borrower has the DATEV service for exporting accounting data enabled
  • Enabling that service runs through your customer success manager at Maesn
  • The credentials behind the connection carry that export service, which Maesn configures
  • Your application meets the interface requirements DATEV publishes for partners
Facts and conditions both from the DATEV guide and the four endpoint references. The second DATEV product is the mirror image: it writes booking proposals, expenses and files rather than reading a ledger.

This is the most complete underwriting route the documentation describes, and it is also the narrowest. It is the only connected system that documents sums and balances, the journal with its lines and the fiscal years together. It is also the only one whose reads sit behind a service the borrower has to have switched on first. A plan that assumes the bundle without the gate is planning on the wrong system.

The gate is worth reading as a signal rather than as friction. The reason this data is reachable at all is an early-access arrangement with the system the German market keeps its books in, and the reason it is gated is that the same market treats that data as the accountant's. Your application also has to meet DATEV's own interface requirements, which are theirs rather than ours and are worth reading early. The system page for DATEV Rechnungswesen lists what it supports object by object, and DATEV Unternehmen Online is the writing counterpart if a product ever needs to put something back.

Outside that route the picture is thinner, and one coupling is worth knowing before it costs a sprint: the trial balance request requires a fiscal year start date as a parameter, and fiscal years are themselves readable at only two systems. Sage Active documents sums and balances as a single figure per account rather than a value per month, and it is not one of those two, so the date would come from somewhere other than the system you are asking. Business Central and Exact Online are the two that document open items, which no other part of the bundle reaches. The system directory has a country filter, and for a lender the useful move is to check the mix in the book you already have before assuming a market.

Where our job ends

We hand over the bookings, you keep the credit model

Everything on the right is either regulated, proprietary or both. A shared layer that reached into it would be selling the same credit policy to competing lenders.

What Maesn absorbs
  • One shape for every ledger
  • Authorization per borrower
  • Each system's own vocabulary
  • Their yearly breaking changes
What stays yours
  • The risk model and the limit
  • Which covenants you monitor
  • What a warning signal is
  • Everything your regulator sees

Three things are absent, and all three come up in a technical review anyway. There is no credit score and no default probability. There is no statement in a national format, because a trial balance is sums and balances per account and the rest is analysis. And there are no bank movements to read: the reference has no endpoint for reading transactions at all, so a model that wants them takes them from a banking provider. Feeding transactions in is the reverse, and for a lender it is a different product with a different licence question behind it: that route is documented and has its own page.

What we do carry is the part that never stops. The interfaces underneath do not hold still, and for a lender that lands as a release-management problem rather than an integration one: a field that disappears in a vendor's spring release is a scoring input that stops arriving on a Tuesday. Holding the shape constant while the systems move is the work being handed over. For an institution the second half of that matters as much: nothing from a borrower's books is retained on our side, what is kept is the record that a transfer happened, and the security posture sets out the certifications and the hosting behind that claim. Where a compliance function rules out a hosted component entirely, the MCP server is documented in a local variant for that requirement.

Which of your own teams ends up owning the connection is a separate question from all of this. It is usually the engineering side rather than the team running the model, and the split above is worth agreeing between the two before a first integration rather than after it.

Banks & lenders FAQ

Common questions

We already receive annual financial statements. What does a direct connection add?

Detail and timing, in that order. An annual statement is a summary at one date, prepared by somebody else and read back out on your side. A connection to the ledger it summarises gives you the accounts, the fiscal periods, the payment terms and the individual bookings, which is a different quantity of evidence rather than the same evidence sooner. The timing follows from it: the borrower authorises access during the application instead of starting a request that runs through their tax advisor and back.

Which banks or lenders already run on this?

None that Maesn publishes. The customers named on this site are financial products of other kinds, from payables automation to collections and expense management, and no bank or lending institution appears among them. What carries this page instead is a documented route rather than a reference: the DATEV Rechnungswesen guide, the four endpoint references behind it and the per-system field lists they publish. If a named lending reference matters for your evaluation, ask for the current state of that directly.

Do you deliver a Jahresabschluss or a BWA?

No, and neither exists as an object in the API. What is documented is sums and balances per account, the journal entries behind them, and the fiscal years they fall in. At DATEV Rechnungswesen the trial balance also documents a value per month rather than a single balance, which is the granularity a period comparison is built from. Turning that into a statement in a particular national format is analysis, and it stays on your side because the format is your regulator's rather than ours.

What does the borrower actually have to do?

Authorize once, in your flow. They pick their company and grant access, and from that point the reads happen without them. For DATEV Rechnungswesen there is a real precondition attached: the service for exporting accounting data has to be enabled in their DATEV account, and switching it on runs through your customer success manager at Maesn rather than through a setting in your product. Worth putting in the application flow rather than discovering it in the first deal.

How current is the data once the loan is running?

That depends on the system, and the answer is uneven enough to design around. Refreshing without re-reading everything means asking a system what has changed since a timestamp, and of the six systems that return journal lines, four document that filter and two do not. The two that do not include the system that carries the initial decision most completely. Where the filter is missing, a review reads the period again and compares on your side, which is more traffic rather than a blocked path.

Does Maesn score the borrower or make a recommendation?

No. There is no score, no rating, no default probability and no decision anywhere in what we deliver. The model that turns a ledger into a limit is the part you are regulated on and the part that distinguishes you from the lender next door, and a shared layer that produced it would be a shared credit policy. What arrives is the same set of objects in the same shape whichever system the borrower keeps their books in.

Can we get bank transaction data through this as well?

Not for reading them, and reading is the direction underwriting wants. There is no endpoint for reading transactions at all, and the transaction object in this model is defined as covering what the other models do not rather than as bank activity, so it would be the wrong object even if the read existed. Account records themselves can be read at a few systems. The other direction does exist and is a separate product question: posting transactions into a ledger is documented and has its own use case. For a risk model that wants bank movements next to the ledger, that is a second data source with a banking provider behind it.

We are a regulated institution. Where does the data sit?

In the borrower's accounting system, and in yours once you have read it. Calls are processed as they arrive and their contents are not kept here, so no copy of a borrower's books accumulates on our side. A supervisory review then has four things to establish and none of them needs us in the room: the hosting is German, the certification is ISO 27001, the processing is GDPR-compliant, and the arrangement was built for DORA rather than retrofitted to it. Where a compliance function rules out a hosted component altogether, the MCP server is documented in a local variant for that case.

We do leasing and factoring rather than lending. Is this the same data?

Largely, and the difference is in what you weight rather than in what you fetch. All three assessments look at the same ledger: the accounts, the movements, the open items, the terms behind the receivables. Factoring leans harder on the receivable side, leasing on the asset and payment history. There is no separate documented recipe for either, so the honest description is one route with three different readings rather than three products.

Most of our borrowers have their books at a tax advisor, not in-house. Does that break this?

That case has the best documented route of any. In the German market the advisor works in DATEV, and DATEV Rechnungswesen is the system this page keeps pointing at: the API reads the same place the advisor's export was produced from. The borrower still authorises it, and the advisor is no longer a step in your process. Outside that market the books tend to sit with the company, and then the system is whichever one they chose.

A borrower uses a system that is not on your list. What then?

Ask about that one system rather than reading a total. A vendor's documentation carries three states and not two: supported now, impossible in that system at all, and on demand in between. The middle state is worth exactly what its definition says, that the object is feasible, that it can be implemented for you and that it is off today. For one named borrower's system somebody can answer that. For a portfolio projection it is not a number, and treating it as one is how a coverage promise gets made by accident.
Related industries
B2B FintechPlatforms whose product depends on the customer's accounting system.Learn moreSaaSSoftware that manages the work and then has to bill it.Learn moreEnterprisesMulti-entity groups whose own IT builds on the ledger.Learn more

Build once on the Unified API.

See how lending data access works for your integration, or dive into the technical reference.

Book a demoRead the docs