Lanes & Planes turns a trip into postings DATEV can take.
Lanes & Planes is a business travel platform for mid-market companies: every employee books their own flights, hotels and train tickets inside it, and the bills for what they booked arrive there rather than in accounting. What accounting needs is each item on the right vendor account with its cost centre, and it needs that even though the payment arrives as a single invoice.
Lanes & Planes, and our half of it
- Website
- lanes-planes.com
- About Lanes & Planes
- Founded in Munich in 2017, with more than 200 employees and over 1.700 companies on the platform. Backed by Smash Capital, Battery Ventures, DN Capital and Coparion, plus a double-digit million growth facility from BBVA closed at the end of 2025.
- Who it serves
- Mid-market companies whose people travel often, with every employee holding their own access and booking their own trips. Rail, airlines and hotels are booked in one place, inside the platform.
- Use case
- Supplier data and travel bills reaching the accounting system together. The workflows themselves, independent of any one platform, are on the supplier data sync page and on accounts payable automation.
- Accounting system
- DATEV Unternehmen Online, the product behind the DATEV feature its own accounting page names for this route
- The payment side
- A single creditor principle, published by Lanes & Planes: all items reach the company on one invoice, paid in the usual invoice run. Nobody has to put a trip on a company card.
One invoice, and a vendor account for every item
A trip is not one purchase. It is a train ticket, a hotel and a flight, from three companies, and the accounting side has to see all three even when the payment is one line.
Consolidating the payment is the part Lanes & Planes already solved and publishes: one correct invoice for everything booked, settled in the usual run, no company card in an employee's hand. That removes the reimbursement work and leaves the harder half untouched. The booking still has to name the rail operator, the hotel and the airline separately, put each on its own vendor account, and carry the cost centre the traveller was assigned. The platform's own page says exactly that: posting records created with the accounts they belong on, vendor accounts included, and cost centres taken into account.
So the preparation is finished before accounting sees anything, and the only question is what the target system will accept. That is where the wording of the task stops matching the shape of the systems. Transferring an incoming invoice sounds like writing a bill, and a bill can be created on three of the 30+ connected systems, on neither DATEV product, with its line items writable on none of them at all.
The posting arrives ready to book
What travels is the finished posting record and the document behind it. The two halves of the task, the bill and the vendor it belongs to, take different routes into DATEV, and that is a property of the product rather than of the integration.
Both halves of the invoice are standard writes on that product, and the tax rate the proposal references is readable from the same system. One data model is what lets the same posting record serve a different target without being rebuilt, error handling decides whether a transfer that fails halfway is visible or silent, and the vendor is where the two DATEV products part ways — the person account is created on DATEV Rechnungswesen and not on the one that takes the proposal.
The invoice goes in as a document with a booking proposal, which DATEV Unternehmen Online takes and its sibling product does not. A supplier record is a different matter: unsupported on both, because the person account there carries another name, and creatable only on the other one.
Accounting stops rebuilding the trip
The travel data was already complete and already correct. What the connection changes is that it arrives in a form the accounting department can post from.
Travel is the category where the finance team pays for detail twice: once when somebody assembles it, again when somebody checks it. Lanes & Planes removed the first half by collecting the bills itself, and the connection removes the second by handing the result over as a posting — the same work financial teams do when they read data out of several entities, only in the other direction. What decides how far the shape reaches is not how many systems exist but how many take both halves: a vendor record and a way in for the bill, together, on fourteen of the 30+ connected systems. Other platforms in travel hit the same ceiling, because the objects a trip produces do not change with the product that books it.
Common questions
What runs on Maesn at Lanes & Planes?
If the payment is a single invoice, why do vendor accounts matter?
How does an incoming invoice reach DATEV?
Is the supplier created as a record in DATEV?
Are cost centres created in the accounting system?
Could another travel platform use the same setup?
Reads the ledger through Maesn and keeps the bank side on its own connection, then writes the reconciled bookings back.Read the case study
Automates the full accounts payable cycle and posts every payment back into the customer's ERP.Read the case study
Turns tracked project time into draft invoices inside the accounting system the customer already runs.Read the case study