maesn
Use case

Factoring on the invoice your customer issued

Financing a single invoice starts with reading it. Maesn returns the invoice, the debtor behind it and the credits against it from whichever accounting system your customer keeps, in one shape, through one connection.

Book a demoRead the docs
Where the invoice is issued
Your customer's accounting system
One connection per customer
What crosses
invoicescustomers

The same shape whichever system your customer keeps.

Where the decision is made
Your factoring platform
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

The invoice is already structured, and the export takes that away

A factoring decision is made on one invoice and the party behind it. Both exist as records in the system that issued them. Today they reach the financier as a file somebody produced by hand.

How one invoice reaches its financier today
  1. Step 1ExportA person exports the open invoices by hand
  2. Step 2SendThe file travels by mail or upload
  3. Step 3Read inThe financier parses whatever shape arrived
  4. Step 4AssessOnly now can the claim be judged and paid

The clock starts at step one. Not when the invoice is issued, but when somebody gets round to exporting it.

The shape is decided at step one too. Every customer's export template is its own format, and step three pays for it.

The delay is the part everyone notices. A company that finances its receivables wants the money on the day the invoice goes out, and the invoice goes out the moment it is written. What stands between the two is a person deciding it is time to run an export, which is why the funding date has more to do with somebody's week than with the trade behind it.

The second cost is quieter and more expensive. Every customer exports from a different system with a different template, so the financier receives the same commercial fact in a different arrangement each time. Building an assessment on that means writing a parser per customer, and every parser is a place where an amount can be read as gross when it was net, or a date as the invoice date when it was the due date. A mistaken reading here is not a formatting problem, it is a mispriced risk.

Both costs are created at the same moment, and neither of them is created by the invoice. The record in the accounting system already carries a number, a date and a status on every system that returns invoices, and an amount and a due date on all but one of them, under the same field names throughout. The export is a copy of that record with the structure removed, sent to somebody who then has to put it back.

How Maesn solves it

One connection per customer, and a documented path through it

Your customer authorises access to the system their invoices already live in. From there the read path is the same whichever system that turned out to be.

  1. 1
    Connect once

    Your customer authorises access to the system their invoices already live in.

  2. 2
    Pull the list

    A filtered read returns the invoices you care about rather than the whole ledger.

  3. 3
    Open one invoice

    The detail call adds the line items behind the total.

  4. 4
    Take the original documentdocumented on 9 of 13

    The PDF the debtor received, through the same connection.

  5. 5
    Include what was uploaded, not issueddocumented on 5 of 13

    Invoices captured into the system from elsewhere arrive as booking proposals.

The first three steps are the ones every financier needs and they hold across the systems that return invoices at all. The last two are worth checking per customer rather than assuming, and that is what the counts beside them are for. Onboarding a customer is an authentication rather than an integration project, and the object shapes that come back do not depend on which system they chose, which is what the common data model is for. The mechanics of the connection itself are described under unified authentication.

The system tells you
7 of 13

An invoice event fires and you read the single record it names, so a claim reaches you when it appears rather than at the next export.

Business CentralExact OnlineLexware OfficeQontoQuickBooksWeclappXero
You ask on a schedule
13 of 13

An incremental read returns what changed since the last one, so the cost of asking stays proportional to what actually moved rather than to the size of the ledger.

  • Filter by what changed11
  • Filter by invoice status10
  • Filter by due date1

When you find out is a separate question from what you can read, and it is the one that decides whether financing happens on the day of issue. Where the system raises an invoice event you learn about the record as it appears and fetch that one; the mechanics and the per-system differences are on the webhooks page. Where it does not, you ask, and an incremental read returns what moved since the last one rather than the ledger again.

The filters underneath decide how much of that ask is useful. Reading only what changed is documented most widely; filtering by invoice status is close behind; filtering by due date is documented on one. Status is the one to select on: it carries open, partially paid, overdue, paid or cancelled, and it is the field that is populated across systems. A second field named after payment exists on a handful and is mostly empty even there, so it is worth reading where present and not worth filtering on. So the shape that generalises is to pull what changed and apply your own selection to the result, which also keeps the response sizes predictable. Paginated, filterable reads cover that, and where a system answers a large read as a background job it arrives as a task you poll.

What you get

Four questions about one invoice, and how far each one gets

A financier asks the same four things about a claim before buying it. Counted across the systems that return invoices, so the four numbers are comparable to each other.

The questionSystems that answer it, of 13
  • Which invoice is this?13
    invoiceNumber · invoiceDate · status

    Documented on every system that returns invoices.

  • What is it worth, and when is it due?12
    totalAmount · dueDate

    Not documented on Xentral.

  • Who owes it?9
    contactId, and the customer record it points at

    The invoice carries no pointer on BuchhaltungsButler and Xentral. On odoo and Qonto the customer object is not a plain read.

  • Has this debtor paid us before?6
    paidDate

    Not documented on Business Central, Exact Online, Lexware Office, QuickBooks, Sage Active, Weclapp, Xentral.

That shape sets a build order. The claim itself is the best covered thing in the whole model, so a first version that prices an invoice on its number, amount, due date and status works on effectively every customer you can onboard. The two questions that narrow are the ones a risk team asks second, which means they belong in the product as conditions rather than as assumptions.

The third question is the one worth reading twice, because its two reasons behave differently over time. A missing pointer is a property of the system, so it is the same for every customer on it and can be decided once. A customer object that is not a plain read is a property of the connection, so it belongs in the onboarding check for each customer and can change without your integration changing. A product that folds both into one capability flag will be wrong about half of them. What a partial response looks like when a system omits a field is unified error handling, and the per-system differences that survive normalisation are the subject of customisation handling.

The last question is the one with the most business value and the least coverage, and that is not an accident. Whether an invoice is settled is a state the accounting system has to keep. When it was settled is a fact about the debtor, and a system that has no reason to expose that will not. Reading how a company's customers actually pay, across all of its receivables rather than one, is a different use case: financial analysis and forecasting.

Proof

A finance product already runs on this connection

Published customer
Tilta
Tilta builds embedded finance software on this API.

Maesn publishes that category in its own customer list. What they build with the connection 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.

Book a demoRead the case studies
4.8on G24.8 out of 5 stars on G2
Key facts

What a financier reads, counted per system

The objects a factoring flow touches, taken from the per-system documentation rather than from a summary.

Across the 30+ connected systems
What you needTodayOn demandSystem cannot
The invoice, with status, amount and due date13142
The debtor record behind it2027
An event when an invoice changes8174
Credits against the same debtor5195
Payments as an object of their own4187
Open items as an object of their own2225
Read from the per-system documentation. The top two rows are the ones a factoring flow rests on, and they are among the deepest in the model. The bottom three carry names that sound like they belong here and are thin enough that a build plan should not assume them.

The bottom three rows are worth reading as a warning about vocabulary. Open items are what a financier calls the thing it wants, and as an object of their own they are readable on two systems. The documented route to the same fact is the invoice list, filtered by status and due date, which is why the first row carries this use case and the last one does not. Payments as a separate object are equally thin, and the settlement information a financier needs sits on the invoice instead.

The debtor is the other place where a name and a number are not the same thing. Company name, street, city, postcode and email arrive from every system that returns customers, which is enough to show a human who owes the money. A VAT identification number, which is what a counterparty check runs on, is documented on two of them. Keeping customers aligned between your platform and the system they came from is customer and supplier data sync, and the same records seen from the collections side are debt collection.

The systems a European factoring provider meets most often here are worth reading before scoping, because they differ more on these endpoints than the totals suggest: Xero, Lexware Office, sevdesk, Microsoft Dynamics 365 Business Central and Qonto. How the connection is hosted and secured on the way through is described on the security page.

Where the line runs

We deliver the claim, you decide what it is worth

Factoring is a judgement about risk and price. What this connection owes you is the same material to judge from, whichever system your customer keeps.

Maesn delivers
  • The invoice, in one shape
  • The debtor record behind it
  • The original document
  • Incremental reads and events
Your product owns
  • The advance rate and the price
  • The risk model behind it
  • The payout and its schedule
  • The ledger of purchased claims

There is no factoring object in this model, no advance and no risk score. That is a boundary rather than a gap: pricing a claim is the thing a financier is in business to do, and a connection that decided it would be wrong for every provider that has an opinion of its own. What it does mean is that the value of this route is measured in what does not have to be built, which is one integration instead of one per accounting system your customers happen to use.

Nothing here assesses a company, whatever the category name suggests. It returns the invoices, customers and creditNotes a single claim is made of, on a schedule you choose. Judging the business behind the claim, and then watching it for the life of a facility, is business lending and underwriting, and the wider picture of what banks and lenders build on this API is their industry page. Where the invoices being financed are created through the same connection rather than only read, that write path is invoice creation. Deciding which receivables to finance and when is the work of financial teams, on both sides of the transaction.

Factoring FAQ

Common questions

Does Maesn decide which invoices to finance?

No. The advance rate, the risk model, the payout and the ledger of purchased claims are your product, and they are the part a financier competes on. What arrives through this connection is the raw material for that decision: the invoice as the accounting system holds it, the customer record it points at and the credit notes booked against the same party.

What can we actually read off one invoice?

Four things, and they thin out in that order. The identity of the invoice, its number, date and status, is documented on all thirteen systems that return invoices. Its amount and due date are on twelve. The path from the invoice to the debtor record holds on nine. Whether that debtor has paid before is on six. A financier onboarding one customer needs to know which of the four that customer's system stops answering.

Can we see how a debtor has paid in the past?

On six of the thirteen the invoice carries the date it was settled, which is the field that turns a list of open items into payment behaviour. On the others the settlement date is not published as a field, so the same information has to be built from the status changing over time, which means storing what you read rather than asking once. Payment status and payment behaviour are different questions, and only the first is available everywhere.

How do we find out that a new invoice exists?

Two ways, and which one you get depends on the system. On seven of the thirteen an invoice event fires and you read the single record it names, which is the route that responds when the invoice is issued rather than when somebody exports it. One further system raises invoice events without a standard invoice read behind them, which is why that count is seven and not eight. On the rest you ask on a schedule, and an incremental read keeps the cost of asking proportional to what changed. Maesn's own guidance is to choose the lowest frequency the product can live with rather than the highest the rate limits allow.

Can we get the original invoice document, not just the fields?

On nine of the thirteen, through the same connection and with the same four fields on every one of them: the file, its name, its content type and its encoding. Where a financier needs the document a debtor actually received, that removes the reason to ask the customer for a PDF alongside the data. On the remaining systems the structured record is what is available.

Is the invoice amount net or gross?

Gross, including tax, and the same on every system. Where an invoice publishes a net figure and a tax figure alongside it, the total is their sum. On three of the thirteen it is the only amount there is, and on those three the net and tax fields stay empty: BuchhaltungsButler, Fortnox and Lexware Office. So an advance priced on a net base can be derived from the invoice on most systems and not on those, which is worth knowing before the pricing rule is written rather than after.

What about credit notes against the same debtor?

Credit notes are readable on five of the 30+ connected systems. That matters more here than the count suggests, because a credit reduces what a claim is worth after it has been assessed, and a financier that reads invoices without them is looking at a gross figure. Where they are not readable, the position has to be agreed with the customer rather than derived.

Is the debtor identified well enough for us to check who they are?

As a postal identity, yes, and as a legal one, rarely. Company name, street, city, postcode and email are documented on all twenty systems that return customers. A VAT identification number is on two of them, Pennylane and Sage Active. For a financier buying a claim against a named party, that difference decides whether the counterparty check runs on the record you fetched or on your own reference data.

How is this different from your business lending use case?

By the object. Factoring is a decision about one invoice and the party that owes it, so it reads the claim, the debtor and what has been booked against them. Business lending is a decision about a company and then a running view of it, so it reads the accounts and the postings over time. The two share fields and answer different questions, and a platform that does both usually builds them as two flows rather than one.

Do you also cover invoices that were not created in the accounting system?

On five systems, as booking proposals. An invoice that was issued elsewhere and captured into the accounting system afterwards is a different object from one the system created, and a financier looking only at issued invoices would not see it. Where a customer's billing runs outside their accounting software, that distinction is worth checking during onboarding rather than after the first pull.

Is any of this stored on the way through?

No. Requests pass through to the system your customer connected and the response is normalised on the way back, so no copy of anybody's receivables is held in between. For a financier that removes a data protection question from the integration, and it removes the risk of assessing a claim against a copy that has since moved on.
Related use cases
Accounts ReceivableIssue, track and settle receivables in every system.Learn moreAccounts PayablePost bills and payments into your customers' ledger.Learn morePayment ReconciliationDeliver reconciled bookings into any accounting system.Learn more

Build once on the Unified API.

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

Book a demoRead the docs