maesn
By industry

Travel platforms hold the trip, the ledger takes it line by line

Your users book the flights, the hotels and the rail legs in your product, and the trip already knows its amounts, its rates and the cost centre it belongs to. Maesn posts it into your customer's accounting system.

Book a demoRead the docs
The documented examplePOST /expenses
what it is for
“credit card transactions or travel expenses”
the expense
Expense_07/25 for business trip
15 July 2025 · EUR 119 gross, 100 net
expenseLines[0]
Gasoline for business trip
account
4900
tax rate
Tax19, 19%
dimension
CostCenter
its name
Material/Waren
The receipt, on the same requestfiles

An extract from the request example Maesn publishes for creating an expense. The wording, the cost centre and the trip are all theirs.

Trusted by winning software teams
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinProvetHeroHolviLanes & PlanesHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinProvetHeroHolviLanes & Planes
4.8on G24.8 out of 5 stars on G2
The problem

A trip is one booking to your users, and a stack of lines in their books

There is no trip in an accounting system. There is one documented object shaped closely enough to carry one, and this is what fits into it and what does not.

One booked trip, as the accounting API documents it
documented at seven systems
The trip, as one expenseonce
Who was paid5 of 7
supplierId
The receipt6 of 7
files
How it was paid1 of 7
paymentType
Every booked item, as one lineexpenseLines[]
Which account it books to7 of 7
accountId
Its own tax rate7 of 7
taxRate
What it was6 of 7
description
The amount, gross4 of 7
totalGrossAmount required
The amount, net3 of 7
totalNetAmount required
Your booking reference3 of 7
documentNumber
The cost centre, the field this industry needs most2 of 7
dimensions on the line, documented at DATEV Unternehmen Online and Xero.
What a booking carries and the expense has no field for
The travel period
A booking runs from one date to another. What the expense carries is a single transaction date.
The traveller
There is no employee object anywhere in the accounting model, so a person has no field to land in.
Counts are the request parameters the create-expense reference lists per integration, across the seven systems that accept an expense, except the two amount rows, which count where the reference marks the field required: every one of the seven requires either the gross figure or the net one. A field missing from a system's list is a field that system's entry does not document, which is worth asking about rather than assuming either way. The account slot itself is named accountId, accountCode or accountNumber depending on which of the seven you are writing to.

The container is an expense, and the documentation describes it as a grouping with each individual expense recorded in the lines object. That is a booking, described by somebody who was not thinking about travel: one document for the trip, one line for every item on it, and every line free to point somewhere different. It has to be free, because a rail leg and a hotel night are not the same category of spend and rarely carry the same rate.

So the job is the split. Someone has to decide which account each item books to, which rate applies to it and which part of the business carries it, and without a connection that someone is a person with the confirmation open in one window and the accounting system in the other. A travel platform meets that as a recurring feature request. The finance team at the other end of it meets it as a monthly afternoon.

What the diagram above adds is that the split is not the end of it. The seven systems that accept an expense do not agree on what an expense line contains. Four require the amount gross and three require it net, so the format is the target system's decision rather than yours. Six take a description on the line and one does not. The cost centre, which is the field this industry is actually about, is documented at two. Those differences are the reason a travel platform that integrates directly discovers its second accounting system is not much cheaper than its first, and they are the reason the same product reaches all of them through one data model here.

How Maesn solves it

The rules are set once per customer, every trip after that is one call

Read the documented expense guide and the balance of it is striking. Almost every step happens once, when a customer first connects, and it is all about learning their structure rather than sending yours. What repeats for every trip afterwards is a single write.

Once, when a customer connectsTheir structure, not yours
Your user connects their systemmaesn Connect
Their chart of accountsGET /accounts
Their tax ratesGET /taxRates
Their suppliersoptionalGET /suppliers
Their cost centresoptionalGET /dimensions
Your categorization rulesin your product
one connection
Then, for every booking
The trip, its lines and the receipt, in one requestPOST /expenses

No second pass to enrich it. The account, the rate and the cost centre were settled by the rules above, and the guide is explicit that those rules are business logic your application owns.

The setup half is where the coverage numbers bite. Reading a chart of accounts is supported at nineteen of the connected systems and reading tax rates at twelve, so for most customers you can present their own accounts and their own rates rather than a translation of them. Reading the configured cost centres is supported at three, and that is why the guide marks that step optional. Where a system holds a field the shared schema has no place for, reaching past the model returns it without a fork of your integration.

The per-trip half is deliberately thin, and one detail in it is worth knowing before you plan a rollout. DATEV Unternehmen Online, which is both the largest German target and one of the two systems that keep a cost centre on the line, takes this write asynchronously: the call is accepted and the result is confirmed afterwards through a task lookup. That is a different shape of success than an immediate response, and a product that treats every write as instant will find out about it on the busiest system rather than the quietest one.

Which customer, and which of their companies, a call belongs to is settled by one authentication layer rather than per vendor, and the full sequence with the endpoint behind each step is on the expense synchronization page, which this page hands the mechanics to instead of restating them.

What you get

More systems take the posting than take the expense endpoint

A travel platform inherits its customers' accounting systems and cannot choose them. So the useful question is not whether one endpoint exists but which of the connected systems can receive a trip at all, by any documented route.

Systems that accept a posting through at least one documented route
12 of 29
Their accounting systemExpenseJournal entry
Business Central
Exact Online
QuickBooks
Twinfield
Xero
bexio
DATEV Rechnungswesen
DATEV Unternehmen Online
Dinero
Fortnox
Lexware Office
odoo
A filled dot is a write the system's own documentation supports today. Five systems take both routes and the other seven take exactly one, so for most customers the route is chosen for you by whichever system they are on.

Two routes are documented and the guide points at the second itself, noting that a simplified way to post expenses is to create bookings directly. The expense object is the richer of the two, since it is the one built to carry lines with their own rates and a receipt. A journal entry is the plainer one and reaches systems the expense endpoint does not, including DATEV Rechnungswesen and the Nordic platforms.

Reading the table by column is the part that pays off in a roadmap. Xero and Business Central take both, so a customer on either can be served whichever way you build first. DATEV Unternehmen Online takes only the expense, and it is also the one that keeps your cost centre, so for German customers that route is the route. The system directory has a country filter, so the way to size this is to check it against the customers you already have rather than against a market you might enter.

The reads behind all of it are reusable, which shows up later rather than in the first release. A platform that has fetched a customer's accounts, rates and counterparties for expenses has already done the fetching that delivering reconciled bookings needs, and keeping suppliers aligned is the same call in the other direction. The second workflow is a feature rather than a project.

References

One published travel customer, and a reference example to match

This industry has a thinner customer record than the others in this menu. What it does have is documentation written with travel in view.

Travel management
Lanes & Planes
Published by Maesn as a travel management SaaS

The category is Maesn's own wording beside the logo in its customer row, which makes it a designation rather than a story. What Lanes & Planes built with it is published nowhere, so it is not on this page either.

Read the Lanes & Planes case study

The rest of Maesn's published customers sit in neighbouring categories, and the closest of them is an expense management platform rather than a travel one.

Book a demoSee all case studies
4.8on G24.8 out of 5 stars on G2

The second reference is unusual and it is stronger than it looks. Maesn's own documentation chose this industry as its illustration twice over, before anybody wrote a page about it. The expense guide names travel expenses in the step where it explains what gets synchronized. The endpoint reference goes further: the request example it publishes for creating an expense is a business trip, described as Expense_07/25 for business trip, with a line for the fuel and a cost centre attached to it. Neither was written to make an argument here.

What that is worth is a matter of what you are weighing. A named customer with a full story tells you the thing has been done. A worked example in the endpoint reference tells you the shape was designed for it, which is a different assurance and the one that survives a technical review. On this page you get one of each, and the honest reading of the customer row is that there is one travel platform in it, not a set.

Key facts

Travel platform object coverage, system by system

Everything above the write depends on reading a customer's own configuration first. These are the objects the expense guide fetches, in the order it fetches them, with what is supported today kept apart from what a vendor's own documentation marks on demand.

What you can read out of a customer's system, across the 29 connected systems
What you needTodayOn demandSystem cannot
Their chart of accounts1982
Their tax rates12143
Their suppliers1928
Their cost centres3179
Their payment terms21413
Expenses already posted4214
Reads only. Which systems accept the write is the table further up, and the two stay apart because a travel product can be stopped by either one on its own.

The first two rows are the ones a categorization interface is built on and they are the healthy ones. The fourth is the one to check per customer before promising anything: cost centres are treated by most accounting platforms as an advanced feature rather than a default, and the numbers say so plainly. Payment terms are thinner still, which is why reimbursement timing stays out of what this connection moves.

The last row answers a question travel products ask more often than others do, which is whether you can see what you already posted. Reading expenses back is supported at four systems, so a reconciliation view that assumes it can compare against the accounting system on every customer will be right some of the time.

On demand in the middle column is the vendor's word rather than ours, and it has a definition worth holding to: the object is feasible, it can be implemented for you, and it is switched off today. A figure there is the start of a conversation about one named system. A roadmap that quietly adds it to the left-hand column is planning on an answer nobody has given yet. How the data behaves once you fetch it in volume is a separate question again, and how filtering and paging behave is where to read about it.

Where our job ends

We put the expense in their books, the trip stays in your product

Two of the things a booking carries have no documented field in any accounting system we connect to. Both stay where they already are, which is in your product.

What Maesn absorbs
  • One expense shape per system
  • Their own accounts and rates
  • The receipt on the same request
  • Their yearly breaking changes
What stays your product
  • Which account an item books to
  • The dates and the traveller
  • Approval before anything is sent
  • What your customers may claim

Everything on the left is a property of the target system rather than of your customer: its authorization, its vocabulary, the shape it insists a write arrives in and the fact that all three move on that vendor's schedule instead of yours. None of it changes depending on who is posting, so one implementation serves every customer you have. Everything on the right does change per customer. One of them books rail travel to a different account than air travel. Another puts every trip under a hundred euros on a single catch-all. That is an accounting policy written one company at a time, and the documentation says plainly that it depends on your application.

The two absences are different in kind. An expense carries a transaction date and not a period, so a trip that spans four days is posted against one of them and the span itself stays with you. There is no employee object anywhere in the accounting model, so the traveller has no field either, and a cost centre answers a different question: which part of the business paid, not who went. Neither of those is a gap we could close by trying harder, and neither is a problem for a product that already holds both. What we do keep on our side is nothing at all from the posting itself, which the security posture sets out in full.

If you would rather check the detail than the argument, the create-expense reference is where the numbers on this page come from: it lists, integration by integration, exactly which request parameters that system supports. Read by role rather than by industry, the same ground is covered for product and engineering teams.

Travel platform FAQ

Common questions

Our product already holds the whole trip. What does the integration actually send?

One expense per trip, with one line per booked item. The documentation defines an expense as a grouping with each individual expense recorded in the lines object, which is the shape a booking already has. Each line carries the account it books to, its own tax rate, its amount and, where the system supports it, its cost centre. The receipt goes on the same request as a file. What you do not send is a second version of the trip: the flight, the hotel and the rail leg stay one booking in your product and become one document in their books.

A trip has items at different tax rates. Does that survive the write?

Yes, because the tax rate sits on the line rather than on the document, and all seven systems that accept an expense document it there. That is the structural reason a mixed trip works at all. It also means the rate has to come from the customer's own system rather than from a table you keep: tax rates are read back from the accounting platform, and twelve of the connected systems support reading them today.

Where does the cost centre end up?

On the line, in the systems that document it, which is the thinnest part of this whole picture and worth planning around. The documentation calls it a dimension and defines it as classes, locations, departments or other dimensions. On the expense route the reference documents a dimension on the line for DATEV Unternehmen Online and Xero. Reading the configured dimensions back is documented at three systems, and those are a different three. On the booking route it is a third set again, namely Exact Online, fortnox, Twinfield and Xero, so the answer for any one customer starts with which system they are on.

Can we attach the receipt to the posting?

The expense endpoint takes files in the same multipart request, and six of the seven expense targets list that parameter. For a travel product that matters more than it sounds: the receipt is what the customer's accountant needs to keep, and it is the piece that otherwise travels by email long after the trip. Note that this is the file riding along with the expense, not the separate document endpoint, which has its own much narrower support.

What happens to the travel dates and the person who travelled?

They stay with you, and the reason is a gap in the model rather than a setting. An expense carries a transaction date, not a period, so there is no field for a trip that runs from Monday to Thursday. There is no employee object in the accounting API at all, so there is no field for the traveller either. The nearest documented stand-in is a cost centre, which answers which part of the business paid rather than who went. Anything finer belongs in your product, and your product is where anyone would look for it.

A trip gets cancelled. How does the reversal reach the books?

That is a per-system answer today rather than a general one. Xero's expense takes an explicit type of EXPENSE or REFUND, so the reversal is a documented case there. For the other six the reference documents no refund type, which means the correction follows whatever that system's own accounting expects and is a question about one named system rather than about the integration layer. Ask it early if cancellations are a meaningful share of your volume, because in travel they usually are.

Our customer is not on one of the systems with an expense endpoint. Are we stuck?

Often not. The guide itself points at creating bookings directly as a simplified way to post an expense, and that route is a journal entry. Counted across both, twelve of the connected systems accept the posting against seven for the dedicated expense endpoint, and the table on this page names which system takes which. The trade is in how much of the trip survives, because the expense object is the one built to carry lines with their own rates and a receipt.

A trip is booked in one currency and reimbursed in another. What is documented?

Less than a treasury product would want and enough for a posting. A currency on the expense is documented at five of the seven targets and an exchange rate at two, so the conversion itself is usually settled before the write rather than by it. The practical consequence is that your product decides the rate it applies and the posting records the result, which is also where a finance team would expect that decision to have been made.

Do we have to build a categorization interface, or does Maesn do that?

You build it, and the documentation says so in the step rather than in a disclaimer: the business logic depends on your application. It gives the range too, from a single dropdown for customers who book everything to one account, up to conditional rules of the form if department is IT then use account A. Nothing in a shared layer could settle that, because it encodes which account a particular company wants a particular kind of spend on. What the layer removes is the part before it, which is fetching each customer's accounts, rates and dimensions in one shape whichever system they are on.

Will the people booking travel ever see Maesn?

Exactly one person in the customer's company meets the connection, and it is not a traveller. A finance administrator authorizes their accounting system once, from a listing in that vendor's marketplace published under your name, in a screen that can carry your brand rather than ours. Travellers keep booking, trips keep posting, and nobody opens that screen again until the company changes accounting system.

Does the expense data sit anywhere on your side?

No. The request carries the expense through and leaves none of it behind, so a security review has one fewer copy of a company's books to trace. Kept is an entry saying a call ran, holding none of what the call contained. Infrastructure runs in Germany, ISO 27001 certified and GDPR compliant. In this industry the sensitive part is rarely the amounts anyway. A trip records who was where and when, and that stays in your product from beginning to end.
Related industries
B2B FintechPlatforms whose product depends on the general ledger.Learn moreSaaSSoftware that manages the work and then has to bill it.Learn moreBanks & Business LendersUnderwrite and monitor on data straight from the books.Learn more

Build once on the Unified API.

See how travel expense sync works for your integration, or dive into the technical reference.

Book a demoRead the docs