Business lending and underwriting on the ledger itself
A credit decision is made on figures a borrower has to collect by hand, and then it is rarely looked at again. Maesn reads the accounts, the postings and both sides of the open position straight from the system the company already keeps, on whatever schedule you choose.
- An invoice that has not been paidOwed to the company, not yet money
- A bill that has not been paidOwed by the company, not yet money
- Which account either belongs toThe structure behind both numbers
All three are records in the accounting system your borrower already keeps.
A decision that waits, and a term that goes unwatched
Lending is not one event. It is a decision, and then a period during which that decision has to keep being right. Today those two halves fail in different ways, and only one of them is usually counted.
The applicant asks their accountant for figures, receives a PDF, forwards it. Every step is a person, and the credit decision waits for all of them.
The loan runs for years and the same request has to be repeated. In practice it happens once a year, because chasing an accountant is a favour you cannot ask often.
The first half is a conversion problem. An applicant who has to fetch figures from their accountant is an applicant with time to reconsider, and every step in that chain is a place to lose them. Speed in the first phase is therefore a growth question rather than an efficiency one, which is not how it is usually budgeted.
The second half is a risk problem and it is quieter, because nothing visibly goes wrong until it does. A picture refreshed once a year is a picture that is on average six months old, and the deterioration a lender most wants to catch, revenue slipping away over two or three quarters, is exactly the kind that a yearly snapshot averages out of existence.
Both halves have the same cause, which is that the data lives somewhere the lender cannot reach. And the thing worth noticing is what is in there: an invoice raised and unpaid is a commitment that has not become money, and neither has a bill received and unpaid. A bank statement shows what moved. A credit decision turns on what has not moved yet.
One connection to the borrower, and the same read for both phases
The applicant authorises access once, during the application. Underwriting is the first read and monitoring is that read repeated, which is why the two phases cost one integration rather than two.
- Customers20
- Accounts19
- Suppliers19
- Invoices13
- Journal entries10
- Bills8
- A profit and loss statement. No endpoint of that kind exists, on any system.
- A balance sheet. The same, and for the same reason: it is a report, not a record.
- The balance on an account. Documented on three of nineteen published field lists.
- Bank movements. Not part of this API, and not what a credit view turns on.
What arrives is the material those are made of: the chart of accounts and the postings against it. Summed per account and per period, that reproduces the figures a credit analyst reads, and it does so identically on every system rather than differently on each.
Reading it is only useful if it means the same thing every time, and that is the part a lender would otherwise build per system. Field names, date formats, country codes and the shape of an account differ everywhere and arrive here already reconciled, which is what the common data model is for. The authorisation itself, including what the applicant sees while granting it, is described under unified authentication, and the per-system differences that survive normalisation are the subject of customisation handling.
A credit file is also a large read rather than a lookup, since it wants a period of postings rather than a record. Paginated, filterable reads keep that proportional, and where a system answers a request that size as a background job it arrives as a task you poll rather than as a timeout. One system documents this exact route as a replacement for the export a borrower would otherwise send by hand, which is the same journey this page describes: DATEV Rechnungswesen.
Three ways to notice a change, and they are not equally available
Underwriting reads a company once. Monitoring is the same read on a schedule, so what decides whether phase two is worth building is not what can be read but how cheaply it can be read again.
| Object | Read it again | Ask what changed | Be told |
|---|---|---|---|
| Customers | 20 | 13 | 6 |
| Accounts | 19 | 10 | 3 |
| Suppliers | 19 | 13 | 6 |
| Invoices | 13 | 11 | 8 |
| Journal entries | 10 | 7 | 3 |
| Bills | 8 | 7 | 3 |
First column: systems where the object can be read at all. Second: systems whose per-system documentation publishes a filter for what changed since your last call. Third: systems that raise an event by themselves. The second column is counted over the systems that publish their fields for an endpoint, which is not always the same set as the first: for postings the documentation publishes nine field lists while ten systems can read them.
The three columns are three different costs. Reading again always works and always costs a full read. Asking only for what changed turns a monthly refresh into something proportional to the borrower's activity rather than to the size of their ledger, and it is available on most but not all of the systems that publish their fields. Being told without asking is the cheapest of the three and the rarest, which is the finding that should shape a monitoring design rather than surprise it later.
What follows is a cadence per object rather than one refresh interval. The receivables side moves daily and is the best served by events; the chart of accounts changes rarely and can be re-read in full without anybody noticing; the postings sit in between and are where the changed-only filter earns its place. A design that picks one interval for everything is either paying for reads nobody needed or looking at a stale ledger, and usually both at once. How the events themselves behave per system is on the webhooks page, and what a partial response looks like when a system omits a field is unified error handling.
None of that is an early warning by itself. An early warning is a threshold your model sets on a series your pipeline keeps, and the only thing this connection owes it is that the series has no gaps and the same meaning in every entry. Where a borrower is a group rather than one company, each entity is its own connection and the same objects come back from each, which is company consolidation.
Lending products are built on this connection
Maesn publishes that category in its own customer list, and nothing about which products they built with it. That is the whole of what this says.
Customers who have published a full account of what they built are collected on the case studies page.
What a credit file is assembled from, counted per system
The objects an underwriting and monitoring flow touches, taken from the per-system documentation rather than from a summary.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| The chart of accounts | 19 | 8 | 2 |
| The postings against it | 10 | 12 | 7 |
| What the company is owed | 13 | 14 | 2 |
| What the company owes | 8 | 17 | 4 |
| The balance per account, as a report | 2 | 7 | 20 |
| The period the figures belong to | 2 | 12 | 15 |
The bottom two rows are each a place where the obvious request and the available route come apart. The period a set of figures belongs to is readable on two systems, so for everyone else the fiscal year boundary is a field on your onboarding form rather than a value the API returns. And the balance report exists on two systems, which is what makes summing the postings the route that generalises.
The payables side deserves more attention than it usually gets in a credit file assembled from bank data, because it is the half a statement hides completely. Across the eight systems that publish their bill fields, fourfields are on every single one: the date, the number, the due date and the gross amount. A lender that reads both sides sees a company's liquidity as a position rather than as a balance, and the same objects seen from the operational side are accounts payable and accounts receivable.
For a regulated lender the questions after coverage are about where the data goes, and the answer is that it does not stay anywhere: requests pass through and the response is normalised on the way back. Hosting, certification and the handling of end-customer data are on the security page. Where an analyst would rather ask questions across a borrower's data than pull it into a model first, that is what the MCP server is for. The systems most likely to appear on a European lending book are Xero, Exact Online, Microsoft Dynamics 365 Business Central and Fortnox.
We deliver the file, you decide what it means
Underwriting is a judgement, and a lender's judgement is its product. What this connection owes you is the same evidence every time, from every borrower, for as long as the facility runs.
- The accounts and the postings
- Both sides of the open position
- One shape from every system
- Reads you can repeat cheaply
- The credit model and the score
- The decision and its price
- Covenants and their thresholds
- What counts as an early warning
There is no risk object in this model, no rating and no covenant. That boundary is deliberate: how a lender reads a set of figures is the thing it is in business to be better at, and a connection that decided it would be wrong for every lender with a view of its own. What it does mean is that the value here is measured in what does not have to be built, which is one integration instead of one per accounting system a borrower might be running.
Nothing here finances a single invoice, whatever the neighbouring category suggests. It returns the accounts, journalEntries, invoices and bills that describe a company, on a schedule you choose. Advancing money against one claim and its debtor is a different decision with a different read pattern, and that is factoring. The wider picture of what banks and lenders build on this API is their industry page, and turning the same figures into a forward view rather than a decision is financial analysis and forecasting. Assembling and defending the file itself remains the work of financial teams on both sides of the loan.
Common questions
Does Maesn score the borrower or make the credit decision?
Can we get a profit and loss statement or a balance sheet?
The docs mention a trial balance. Is that not the same thing?
Can we look into every account and see what is in it?
How current can we keep the picture during the term?
What does an early warning actually rest on, then?
Do you cover bank transactions as well?
How is this different from your factoring use case?
How fast can a borrower be connected during an application?
Is the borrower's data stored anywhere on the way through?
Build once on the Unified API.
See how business lending works for your integration, or dive into the technical reference.