Financial analysis and forecasting on data pulled from the ledger
Accounting systems keep the finished figures to themselves. What they will hand over is the evidence underneath: the postings, the receivables and the chart of accounts. Maesn delivers those in one shape across every system your customers run.
- 10The postingsjournalEntries
- 13The receivablesinvoices
- 19The chart of accountsaccounts
Counted from the per-system documentation across the 29 connected systems.
One report endpoint across every connected system
A forecasting product would happily take the answer if the accounting system offered one. It does not, and the gap between what is computed and what is readable is the whole shape of this integration.
Aggregates the accounting system has already computed.
Documents and master data the aggregates are built from.
Every one of those figures exists inside the accounting system. It knows the balance of each account, it knows which receivables have gone past their date, and it knows when the financial year turns, because it renders all three on a screen the customer looks at every week. What it mostly will not do is answer a question about them through an API, and that is the difference a finance product discovers only after it has promised a roadmap.
It is tempting to read those gaps as a backlog, and for the largest of them it is not one. On the trial balance, twenty of the twenty-nine systems are marked as having no such endpoint of their own, so no amount of integration work opens them. The remaining thin rows are mostly marked on demand instead, and what that marking promises is an open question rather than a date, so the only safe reading is that they are not available today.
The layer underneath tells a different story, and it is the reason this page exists. Documents survive where aggregates do not: the postings, the receivables, the payables, the chart of accounts and the rates behind it all come back in quantity. So the work is not fetching an answer, it is building one, from evidence that arrives in the same shape however many systems your customers run. That is also, usually, what a forecasting product wants. A model somebody else already ran is not a differentiator.
The postings and invoices your model actually runs on
One connection, one object shape, and a per-system truth worth knowing before you build against it: not every ledger returns a posting with a number on it.
- transactionDateWhen it was booked
- descriptionWhat it was for
- journalTypeWhich journal it sits in
The account, the debit or credit side and the amount all live here. Everything a model sums is inside this one block.
Field names from the documented response. The nine field lists published for this endpoint and the ten systems listed as readable are not the same set, and neither one contains the other.
On three of the nine field lists the reference documents no line items, so a posting arrives with a date, a description and a journal code and no figure attached to it.
Of the six that do carry lines, four document the gross amount only, Dinero documents the net only, and Xero documents net, tax and gross together. Summing the wrong one is wrong by the tax on every line.
A posting is the smallest honest unit a financial model can work from. It carries the date, the account, the debit or credit side and the amount, and everything a report summarises is a sum over those lines. Maesn normalises that object across systems, so the code that groups postings into a period, an account or a cost centre is written once rather than once per accounting platform.
Where the normalisation stops is at the fields a given system does not publish, and this endpoint has the sharpest example in the model. Reading the field lists rather than the headline count is what surfaces it: on three of the nine documented systems the response has no line items, so a posting comes back described but not quantified. Counting readable systems and building on the total would put those three in a forecast as postings worth nothing.
The receivable side is the happier one, and it is where most cash-flow work actually happens. Invoices are readable on thirteen systems and carry a status everywhere they are documented, which is enough to age a ledger without an ageing endpoint existing. Bills give the same picture on the payable side. Between them they answer what is outstanding and when it falls due, which is the input a liquidity model spends most of its time on.
Volume is the other half of the problem, since a model that wants history wants years of postings rather than yesterday's. Reads are paginated and filterable in one way across systems, an incremental pull keeps a refresh proportional to what changed, and where a system answers a large read as a background task rather than a response, that arrives as an asynchronous task you poll. The object shapes themselves come from the common data model, and the connection each customer authorises once is described in unified authentication.
A trial balance where it exists, an ageing schedule you build yourself
Where a finished report does exist, here is exactly what it contains. And where it does not, here are the fields that let you build the one a forecast actually needs.
Returns a balance per month per account, plus the opening balance and both totals. That is a time series, which is what a model wants.
Returns the balance as it stands. How the account got there is not in the response, so the series has to come from the postings anyway.
Both require fiscalYearStartDate before they will answer. Fiscal years are readable on two of the twenty-nine systems, and Sage Active is not one of them, so on one of the two systems that return a trial balance the endpoint asks for something that system will not tell you.
The consequence is an importer that cannot be written once. A product that reads “trial balance supported” off a capability list will build for the richer response, ship it, and find that on the other system the same code has one number to work with and no way to see how the account reached it. There the series has to be rebuilt from the postings, which is a second code path rather than a configuration flag.
The parameter dependency is worth planning around for the same reason. Where the fiscal year is not readable, its start date has to reach your request from somewhere else, which in practice means asking the customer during onboarding and storing the answer. That is a field on a setup form if you know in week one, and a migration if you find out in week nine.
- status13 of 13Where the invoice standsOn every documented system.
- dueDate12 of 13When it was dueMissing only on Xentral.
- totalAmount12 of 13How much is outstandingMissing only on Xentral.
- paidDate6 of 13When it was actually paidThe one that models behaviour.
No object in this model is called an ageing schedule, and the first three rows are all it takes to build one: a status, a due date and an amount, bucketed by how far past due each invoice sits. The payable side works identically from bills, which is how the same code produces both halves of a working-capital view.
The fourth row is marked apart because it separates a report from a forecast. Knowing an invoice is overdue tells you where it stands today. Knowing the date it was actually settled tells you how that customer pays, which is the only thing a projection can be built on. Where that date is absent, payment behaviour has to be inferred from status changes over time rather than read, and designing for that from the start is cheaper than retrofitting it once a customer arrives on one of the systems that needs it. Postings are the fallback for both, since that is where a settled payment ends up recorded in the first place.
A finance product already runs on this connection
Maesn names them an AI finance software customer on its own home page. What they built with it is theirs to describe, so that is all this says.
Customers who have published a full account of what they built are collected on the case studies page.
What a forecast reads, counted per system
The rows a financial model touches, taken from the per-system documentation rather than from a summary.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| The postings themselves | 10 | 12 | 7 |
| Receivables and their due dates | 13 | 14 | 2 |
| Payables and their due dates | 8 | 17 | 4 |
| The chart of accounts | 19 | 8 | 2 |
| The rates behind the figures | 12 | 14 | 3 |
| The balance per account | 2 | 7 | 20 |
| What is still unsettled | 2 | 22 | 5 |
| Bank activity | 0 | 21 | 8 |
The last row is the one to plan around, because it is not thin but empty. Bank activity comes back from no connected system at all, while writing a transaction is documented for four. A capability that exists in one direction only is easy to misread from a feature list, and this one is worth reading twice: the object called a transaction here is a residual bucket for records that fit none of the others, not the line on a bank statement.
Events are worth measuring the same way. Postings publish change events on three systems and the trial balance on none, so a product that wants to react to a booking rather than find it on the next sweep can do that for those three and polls for the rest. How that mechanism works, and where its edges are, is the subject of unified webhooks. The per-system differences that survive normalisation, of which the amount basis above is one, are covered in customization handling, and what a partial response looks like when a system omits a field is unified error handling.
The systems in this bracket that a financial product meets most often are the German and Dutch ledgers, and their behaviour on this endpoint differs enough to be worth reading before you scope: DATEV Rechnungswesen, which is the one system here that answers a ledger read as a task rather than a response, Exact Online, Xero and Microsoft Dynamics 365 Business Central.
You model, we deliver the numbers behind it
The forecast is your product. What this connection owes you is the material it runs on, in one shape, from every system your customers use.
- Postings with side and amount
- Invoices and bills with dates
- The chart of accounts and rates
- Paginated, incremental reads
- The model and its assumptions
- Which accounts roll up where
- How payment behaviour is read
- Scenarios, budgets and variance
The line sits where it does because of what the data allows rather than where a diagram would put it. Maesn passes requests through to the target system and normalises the response on the way back, so there is no second copy of anybody's ledger to drift out of date. That is a security property before it is an architectural one, and it is the subject of how the connection is built and hosted.
It also means the interesting part stays yours. Two products reading the same postings through the same connection will produce different forecasts, because the difference is the model rather than the pipe. The pipe is what this page is about, and the reason it matters is that building it once per accounting platform is how a finance product spends a year not shipping the model. Neighbouring cases work the same way: what a settlement looks like once it is posted is accounts receivable, the payable mirror is accounts payable, the rates behind the figures are tax automation, and the master data that makes a customer in one system the same customer in another is customer and supplier data sync.
One boundary decides more than the rest, because it is the one the category name invites: this connection does not read bank lines. Bank activity is readable on none of the connected systems, so a cash position assembled here comes from the ledger's own view of what was booked, not from the account itself. If your product needs the bank, it needs a bank connection, and that is a different piece of plumbing with a different set of rules. What arrives through this one starts at journalEntries, once a transaction has become a booking.
A cash position assembled from bookings rather than from the bank is what gets asked of financial teams.
Common questions
Can we pull a profit and loss statement or a balance sheet?
Which systems return a trial balance?
Is the data real time?
Can we read bank transactions for a cash position?
How do we build an ageing schedule without an ageing endpoint?
What is the difference between reporting and forecasting here?
Does a posting always come back with amounts on it?
Can we segment a forecast by cost centre or department?
How much data are we pulling, and how often?
Does Maesn store or model our customers' financial data?
Build once on the Unified API.
See how financial analysis and forecasting works for your integration, or dive into the technical reference.