Accounts receivable automation starts before the invoice
Your product knows the receivable. Only your customer's ledger knows the customer record, the account and the tax rate it has to be posted against. Maesn moves both directions through one connection, then writes the invoice and the payment back.
- The invoice you issued
- The payment you recorded
- The customer, as their books name them
- The account it posts to
- The tax rate that applies
Six of the eight documented steps are about the right-hand side, not about the invoice.
The receivable is yours, the accounting structure is not
Read the documented flow in order and something stands out: almost none of it is about the invoice. It is about agreeing with somebody else's ledger before you write to it.
- sync contactsAgree on who the customer is
- GET /accountsThe general ledger account
- GET /taxRatesThe rates in use
- GET /dimensionsClasses, locations, departments
- categorizationHow your users map it all
- POST /invoicesOr a booking proposal
- POST /paymentsThe money against it
Only one of the seven is about the invoice itself. The first is a separate use case, two are optional, and the rest is the customer's own accounting structure, which is the part your product does not hold.
The first step is not a call at all, it is another use case. The guide opens by asking you to implement contact synchronisation, so that the customer in your database and the customer in your user's accounting platform are demonstrably the same party. That is not bureaucracy. A receivable booked against a near-duplicate customer record is the kind of error nobody notices until a statement goes out, and then it is somebody's afternoon. That work has its own page under customer and supplier data sync.
After that come the structures: the general ledger account the invoice posts to, the tax rates in use, and the dimensions their setup expects if they use any. None of these live in your product, all of them differ per customer, and each one is a place where an otherwise correct invoice becomes a correction. The tax rates in particular are less uniform than they look, which is a subject of its own under tax automation.
Only then does the invoice appear, and by that point the interesting question is no longer how to send it. It is which of the two documented routes it should take.
One connection that reads the structure and writes the receivable back
The same objects under the same names on every connected system, in both directions, so the mapping your users configure once keeps working when the next customer arrives on a different platform.
The reads arrive as one normalized shape, which is what makes the categorisation step buildable at all. You fetch the accounts, the rates and the dimensions, you present them in your own interface, and your users decide how their receivables map onto them. The documentation is unusually concrete about how far that can go: a single ledger account chosen from a dropdown, conditional rules of the kind if Department = IT, use Account A, or a choice made at the moment of transfer that overrides the stored configuration. Your product owns that logic. What it needs from the connection is that the options are real and current.
Writing back is where the direction matters. A receivable is money owed to your customer, so it posts as an invoice and a payment against a customer record, not as the mirror image on the payable side. That distinction is easy to lose in an integration layer that treats both as documents with amounts on them, and it is the reason the payable side has its own page rather than a paragraph on this one.
The customer record itself is the strongest part of the chain, which is convenient given the flow starts there. It reads on twenty of the connected systems and writes on sixteen, so keeping both sides in agreement is not a special capability you have to check per system. Authentication for all of it is one flow your customer approves once, whatever their system is.
Create the invoice, or upload the one you issued
The guide offers two ways for a receivable to reach the ledger, and they answer different questions about where the invoice came from. They are supported on the same number of systems, which is where a first reading stops being enough: the counts match and the system lists do not.
Create it in their ledger
Your product is where the invoice comes into existence, so Maesn writes it into the customer's accounting system with the account, rate and dimensions their setup expects.
Upload the one you issued
The guide names this route for the case where the invoice was already created on another platform. It arrives as a proposal to be booked rather than as a fresh document.
Only five of the connected systems support both routes, five more take a created invoice but no booking proposal, and another five take a booking proposal but no created invoice. Which route you need is therefore partly decided by the systems your customers run, not only by where the invoice was born.
Which route fits depends first on where the document is born. If your product is the system of record for the invoice, you create it in the customer's ledger and it arrives as a real document with your account, rate and dimension choices attached. If the invoice already exists somewhere else, the booking proposal route is the honest one: it presents the transaction for booking instead of pretending your product issued it. Uploading a document that already exists as though it were new is how duplicates enter a ledger.
The second thing it depends on is the system in front of you, and the split is sharper than the two counts suggest. Lexware Office and Xero take either route, so there the choice really is yours. DATEV Unternehmen Online takes booking proposals and not created invoices, which is not a gap but the shape of the German workflow: documents are submitted to the tax advisor's environment to be booked, they are not issued there. A product that only implemented the invoice route would simply not work for those customers.
After either route the payment is its own step, and its coverage is narrower than the invoice routes. That is worth designing around rather than discovering: a product whose value depends on the payment appearing in the ledger should check that against the systems its own customers actually use. Settling that payment against the outstanding item is the neighbouring job described under payment reconciliation, and where a system emits events, webhooks shorten the loop between the money arriving and your product knowing.
Receivables platforms already run on this connection
Two published customer categories, and the second one is what happens when a receivable stops being a receivable.
Receivables management is this use case by another name, which makes it the closest published category Maesn has to it.
A receivable that stays unpaid becomes a collections case, and that is a platform reading the same objects from the same ledger.
Paywise has told the whole story, including what changed after the integration.
The two sit at different points on the same line. Receivables management is this use case under another name, and collections is what the unpaid remainder becomes. Both need the same things from the creditor's ledger, which is the argument for one connection rather than one per workflow, and the collections end of it is described under debt collection.
Receivable coverage, object by object
The documented flow first, then the two objects a reader might expect here and should not count on. Counted from the per-system documentation, with what is supported today kept apart from what is only marked on demand.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Customer records, reading | 20 | 2 | 7 |
| Customer records, writing | 16 | 4 | 9 |
| Chart of accounts, reading | 19 | 8 | 2 |
| Tax rates, reading | 12 | 14 | 3 |
| Invoices, writing | 10 | 17 | 2 |
| Booking proposals, writing | 10 | 17 | 2 |
| Payments, writing | 6 | 15 | 8 |
| Payment terms, reading | 2 | 14 | 13 |
| Open items, as an object | 2 | 22 | 5 |
The shape of this table is the shape of the use case. It is strongest exactly where the flow begins, at the customer record, and the two write routes are level with each other. That combination is what lets a product promise its users a working receivable sync rather than a working receivable sync on four named systems.
The last two rows earn their place by being weak. The page this replaces named payment terms and open items among the objects it reflects correctly, and at two systems each that was more than the data supported. Where one system holds a receivables structure the shared model has no field for, reaching past the model is documented, and the incremental refresh that keeps all of it current works the same way as it does on every other list endpoint.
We deliver the structure, your users decide the mapping
On this use case the boundary is unusually clear, because the documentation itself puts the categorisation logic in your product and says so.
- The customer, both directions
- Accounts, rates and dimensions
- Two routes for the invoice
- The payment, written back
- Which account a receivable hits
- The rules your users configure
- When a transfer happens
- What your dunning looks like
Everything on the left is the connection doing what a connection should: the same objects, under the same names, on whichever system your customer runs, in both directions. That is the part that would otherwise be one integration per accounting platform, each with its own authentication, its own field names and its own opinion about what a customer record contains.
Everything on the right is your product, and the guide is explicit that this is deliberate. It hands you the accounts, the rates and the dimensions and then says the business logic will depend on your application. Whether a receivable maps to one ledger account or to a conditional rule, whether your users can override it at the moment of transfer, and when a transfer happens at all are product decisions with your customers' accounting conventions behind them. A layer that answered them for you would be guessing at an accountant's intent.
One property belongs here rather than on the security page. Requests are processed as they arrive, and what Maesn keeps is the record that a transfer happened rather than the transferred data. For a product handling other companies' customer and revenue data, holding less of it is easier to defend. The lastModified filter on the read endpoints is what makes staying current cheap without keeping a copy of anybody's ledger.
The people who notice first when a receivable ages are financial teams, before it reaches anyone else.
Common questions
Where does an accounts receivable integration actually start?
How does the invoice get into the accounting system?
What do we need before we can post anything?
Do our users get to decide how transactions are categorized?
Can we post the payment as well, or only the invoice?
You do not mention journal entries. Why not?
What about payment terms and open items?
How do we keep the data current without re-reading everything?
Which systems does this work with?
Does Maesn decide which account or tax rate is used?
Build once on the Unified API.
See how accounts receivable works for your integration, or dive into the technical reference.