Accounts receivable automation starts before the invoice
Accounts receivable platforms require deep, bidirectional integration to correctly reflect customers, accounts, journals, accruals and deferrals, tax rates and open items. Maesn enables these complex AR workflows across dozens of ERP and accounting systems, without building each integration from scratch.
- 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.
Posting receivables is a lot about having the right data for precise mapping
Pull customer data, chart of accounts, dimensions and tax rates from your customer's accounting system as the base for precise mapping logic in your system: the prerequisite for correct postings into the accounting system.
- Which account a receivable lands in
- Whether tax is set or chosen
- Conditional rules per department
- Override at the moment of transfer
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 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 normalised 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 is readable on most connected systems and writable on nearly as many, 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.
Four ways a receivable reaches the ledger
Create the invoice
Your product is where the invoice comes into existence, so it arrives in the ledger as a real document with your choices attached.
Upload the one you issued
The invoice already exists somewhere else, so it is presented for booking instead of being issued a second time.
The payment against it
A step of its own after either route, and the one to check against the systems your own customers use.
The journal entry
The deepest route, and it asks your product for the finished posting. It is also where accruals and deferrals are expressed.
Which of the four an accounts receivable product uses depends on the concrete use case: where the invoice comes into existence, whether your product owns the categorisation, and whether the money has to appear in the ledger as well as the document. Most products need more than one of them over time, and the connection does not change when they do.
We help with that rather than leaving it to a trial build. It also depends on the system in front of you: Lexware Office and Xero take either of the first two, so there the choice really is yours, while DATEV Unternehmen Online takes booking proposals, which is the shape of the German workflow: documents are submitted to the tax advisor's environment to be booked, they are not issued there. Tell us which systems your customers are on and we say which routes are available on each.
Settling the 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 | 16 | 7 |
| Payment terms, reading | 2 | 14 | 13 |
| Open items, as an object | 2 | 23 | 4 |
The shape of this table is the shape of the use case: it is strongest exactly where the flow begins, at the customer record. That 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 barely any system 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 categorised?
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.