maesn
Use case

Accounts payable, all the way into the ledger

An AP product lives or dies on whether the posting lands correctly in the system your customer's accountant actually opens. Maesn delivers the suppliers, accounts, tax rates and dimensions that a correct posting needs, in one shape, across every connected system.

Book a demoRead the docs
Before one bill postsfour reads
Suppliers in sync/contacts
Chart of accounts/accounts
Tax rates/taxRates
Dimensions/dimensions
one shape, every system
The POST call
POST /bills
POST /payments
POST /bookingProposals
POST /journalEntries
Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
4.8on G24.8 out of 5 stars on G2
The Situation

Before posting journal entries, data mapping is required

Accounts payable looks like a write and behaves like a dependency chain. The documented sequence spends most of its steps before the first record is created.

What you pull first
/contactsSuppliers matched
/accountsThe ledger
/taxRatesTax codes in use
/dimensionsClasses, departments
What your product decides
  • Which account a bill lands in
  • Whether tax is set or chosen
  • Conditional rules per department
  • Override at the moment of sync
Then you write, one of three ways
Option 1POST /billsPOST /payments
Option 2POST /bookingProposals
Option 3POST /journalEntries
And then it stays currentThe lastModified parameter works on every GET endpoint, so detecting what changed is a filter rather than a diff you build.

The create call is the short part. A bill needs a supplier it belongs to, a general ledger account it posts against and a tax code the receiving system recognises, and each of those lives in the customer's own configuration rather than in your product. If the customer works with classes, locations or departments, those dimensions have to be read too, because a posting without them is filed in the wrong place even when every amount is right.

That is why the first stage of the sequence is reading rather than writing, and why supplier synchronisation comes first. A bill references a vendor, so if your records and the accounting platform disagree about who that vendor is, you either get a rejected write or a duplicate that somebody has to clean up later. Getting that agreement in place is its own piece of work, which is why it has a use case of its own.

What Maesn changes is not the number of steps but how many times you implement them. The same reads and the same write work the same way whether the customer is on DATEV, Exact Online or Xero, because they arrive through one normalised data model instead of in each vendor's own vocabulary. The sequence stays; the per-system rebuild goes.

Two neighbours are worth naming because they look like this one and are not. Writing the journal entries that follow a settlement belongs to payment reconciliation, and creating an outgoing invoice rather than recording an incoming bill is invoice creation. Both run on the same connection and the same reads, which is why they are worth separating before a build rather than after.

How Maesn solves it

Four ways an accounts payable product puts data into the ledger

The document only

The lightest route. Your product hands over the file and the accounting side takes it from there.

You sendPOST /files
You getthe document in the system

The document and the payment

The same handover plus the settlement, so the document and the money that cleared it arrive together.

You sendPOST /files
AndPOST /payments

The booking proposal

Your product supplies the structured fields, so the result does not depend on what is legible on the page.

You sendPOST /bookingProposals
You supplythe fields, not a scan

The journal entry

The deepest route, and it asks your product for the finished posting. Teams building for smaller businesses usually run one of the lighter routes in front of it.

You sendPOST /journalEntries
You supplythe complete posting

Which of the four an accounts payable product uses is decided by the use case rather than by preference, and by what the customer's system does with the result. A product that only has to get the document in front of the accountant is finished after the first box. One that owns the categorisation ends up further right. Most teams start on the left and move right as their product takes on more of the decision.

We help with that decision rather than leaving it to a trial build: tell us which systems your customers are on and what your product already decides, and we say which route is available on each of them and what it needs. Routes that write asynchronously report back through asynchronous processing, so confirming a long-running write is a pattern your code learns once. Where a system needs its own preparation on the customer's side, that is on its own page, as with DATEV Unternehmen Online.

Proof

An AP platform already runs on this

Tipalti realises their European integrations via Maesn.

“With Maesn, we accelerated our European expansion by making complex ERP integrations seamless across Benelux and DACH. As an AP platform, reliable access to key local ERP systems is critical and Maesn gives us exactly that.”
Saad Abouyahya
Sr. Manager, Global Technology Platforms & Strategic Partnerships at Tipalti
Book a demoRead the case study
4.8on G24.8 out of 5 stars on G2

Tipalti is one of the larger accounts payable platforms and uses Maesn for several ERP integrations, Exact Online among them, to reach customers across the Benelux and DACH markets. The interesting part for anyone evaluating this is what an AP platform needs from an integration layer: not breadth for its own sake, but dependable access to the specific local systems its customers keep their books in.

Where the line runs

We deliver the structures, you set the rules

The documentation is direct about where the line falls, and repeating that line here is more useful than promising accounts payable end to end.

What Maesn absorbs
  • Every system's word for a supplier
  • The connection and its refresh
  • Tenant identifiers, filled in
  • Change detection as a filter
What stays your product
  • Which account a bill posts to
  • Whether tax is derived or picked
  • How rules and overrides behave
  • When a bill leaves your product

The left column is the part that never stops needing maintenance: every system's own vocabulary for a supplier and an account, the authorisation behind each connection and its refresh, the identifiers that say which tenant a call belongs to, and the specific way each platform wants a bill or a payment handed over. Those are absorbed once and stay absorbed, which is the whole reason to build on one authentication layer rather than per vendor.

The right column is your product, and it should be. How a bill is categorised is a decision about your customer's accounting policy, and the documentation says as much: the logic depends on your application. A layer that made that choice for you would be guessing at a policy it cannot see. What it can do is hand you the accounts, the tax rates and the dimensions in a form you can put in front of a user without translating them first.

Read the two columns together and the trade is clear. You keep the decisions that are specific to what you built, and you stop re-implementing the same reads and the same write for every accounting system your next customer happens to use.

Three of those absorptions are worth naming. Asking what changed since the last look is a filter rather than a diff you build, and it behaves identically on every system through one way to filter and page. Where a system pushes instead, one event model gives you a single shape to parse rather than one per vendor. And where a single installation carries a field the shared schema does not, reaching past the model is what keeps that from becoming a fork.

Seen from the other side of the ledger, an approval that never reached the system is a problem for financial teams, who carry the consequence rather than the code.

Accounts Payable FAQ

Common questions

What does it actually take to post one bill into a customer's accounting system?

More than a create call. The documented sequence starts with suppliers: they have to exist and match on both sides, or the bill has nothing to attach to. Then you read the chart of accounts, because a bill needs a general ledger account, and the tax rates, because the amount needs a tax code the system recognises. Dimensions come next if the customer uses classes, locations or departments. Only then does the write have everything it needs, whichever of the four routes on this page your product uses.

Do we have to synchronise suppliers first, or can we skip that?

The documentation makes it the first step, and the reason is practical rather than procedural. A bill references a supplier, so if your database and your customer's accounting platform disagree about who that supplier is, the write either fails or creates a duplicate vendor. Getting that agreement in place first is what makes everything after it repeatable.

Who decides which account a bill is posted against?

Your product does, and the documentation is explicit that the business logic depends on your application. Maesn delivers the accounts, tax rates and dimensions in one shape so you can present them in your own interface. Whether that becomes a single dropdown, a rule like posting IT department costs to one account, or a choice your user makes at the moment of export is your design decision.

Can we read bills as well as create them?

Yes, and in more detail than a list. GET /bills returns bills filtered by criteria such as bill date or status, GET /bills/{id} returns one bill in full including its line items, and there is a separate endpoint for the original document. Bills that were created somewhere else and uploaded to the accounting platform are reachable through the booking proposal endpoints.

Can we show our users the original invoice document?

Yes. GET /bills/{id}/document returns the original PDF as it sits in the accounting system, and captured documents have the equivalent endpoint under booking proposals. That matters for approval flows, where somebody has to look at the document itself and not only at the numbers read off it.

What is a booking proposal?

It is the object for a document that entered the accounting system without being created there. A supplier invoice you captured in your product and pushed across arrives as a booking proposal for the accountant to confirm, rather than as a finished posting. It is also how you reach bills that were captured elsewhere and uploaded since.

What is the difference between uploading a document and uploading data with it?

They differ in who reads the invoice. Upload the file on its own and the accounting system runs optical character recognition over it, which means the result is only as good as what it can see on the page. Send the structured data alongside the document and you can provide more detail than the document shows while avoiding mistakes from character recognition. The second route asks more of your product and gives a more predictable result.

What is a journal entry?

It is the record of a single accounting transaction in the ledger, written as balanced debit and credit lines against the accounts they belong to. It is the form bookkeeping settles into, which is why posting one asks your product for a complete posting rather than a document: the accounts, the amounts and the tax treatment all have to be decided before the call. That is the difference between the journal entry route on this page and the lighter ones in front of it.

How do we know an upload actually went through?

Where a route writes asynchronously, GET /asyncTask reports whether the upload was processed. That is the same asynchronous task mechanism used elsewhere in the API, so the pattern for confirming a long-running write is one your code learns once rather than one per route.

How do we keep everything current after the first sync?

With a filter rather than a comparison. The lastModified query parameter works on the GET endpoints, so asking for what changed since a point in time replaces building and storing your own deltas. Where a system emits events, webhooks make the same job cheaper still, and the documentation flags them as the more efficient route.

Does every connected system support every part of this?

No, and there are three cases. Some objects are enabled today across most systems, some are switched on when a use case needs them, and for some the target system has no equivalent concept at all, which no integration layer can create for it. Which of the three applies is answered per system rather than as an average, so tell us which systems your customers are on and we confirm the routes that work on each.
Related use cases
Accounts ReceivableIssue, track and settle receivables in every system.Learn moreExpense ManagementPush expenses into the accounting structure in place.Learn moreFinancial Analysis & ForecastingRead the ledger, invoices and accounts a forecast needs.Learn more

Build once on the Unified API.

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

Book a demoRead the docs