Five industries, and one system they do not own.
A payables platform, a construction app, a lender and a group finance team have almost nothing in common, until each of them needs something out of, or into, the accounting system their customer keeps the books in. What differs per industry is which objects that means.
Start with the one that describes what you are building
Each page is written for one buyer and carries the objects, the systems and the customers that belong to it.
- B2B FintechPlatforms whose product depends on the general ledger.
- SaaSSoftware that manages the work and then has to bill it.
- Banks & Business LendersUnderwrite and monitor on data straight from the books.
- Travel PlatformsTravel bookings that have to land as correct postings.
- Internal Company ConsolidationCompany groups whose entities each run their own system.
One connection, a different set of objects in each
Every industry below meets the same systems through the same authorization and the same data model. What its workflow asks of that model is where they part.
- IndustryB2B FintechProducesA finance process to completeNeeds from the ledgerCustomers, suppliers, accounts and tax rates in, invoices, bills, payments and journal entries back
- IndustrySaaSProducesAn invoice out of the workNeeds from the ledgerCustomers, the chart of accounts, items and tax rates in, one invoice back
- IndustryTravel PlatformsProducesA trip that has to be bookedNeeds from the ledgerAccounts, tax rates, suppliers and dimensions in, expenses or bookings back
- IndustryBanks & Business LendersProducesA credit decision to underwriteNeeds from the ledgerAccounts, fiscal years, journal entries, payment terms, tax rates and the trial balance, read only
- IndustryInternal Company ConsolidationProducesA group figure to closeNeeds from the ledgerTrial balance, journal entries, journals, fiscal years, dimensions and accounts, per entity
Read down the right-hand column and the shared part is hard to miss. The chart of accounts and the tax rates turn up in four of the five, because almost nothing can be written into a ledger without pointing at an account and carrying a rate. That is the practical case for one data model rather than one integration per market: the objects you learn for the first industry are most of the objects the next one needs, and the systems behind them are the same list either way.
The differences are worth reading as instructions rather than as trivia. A lender only reads, so its integration never has to satisfy a system's write validation and never risks creating a duplicate. A vertical SaaS mostly writes one document, so its work sits in getting that document right rather than in breadth. A payables platform does both all day and meets every awkward edge of both. That is the same connection carrying three quite different amounts of risk, and it is why the estimate for one industry is a poor guide to another.
The industry does not pick the system, your customer already did
Thirty-three accounting and ERP systems across nineteen countries, and the same list serves all five industries on this page.
This is the part that surprises teams planning their first integration. You do not get to choose the system, and neither does your industry: a construction platform in Bavaria and a payables platform selling into the same street both land in whatever their customer's accountant set up years ago. What decides the list is the customer's country and size, which is why the German SME systems and the ones a mid-market group runs, like Business Central, show up in completely different parts of the same customer base.
Underneath the industry differences the hard parts are shared, and they are the reason an integration project is longer than it looks. Every system has its own idea of when a list ends and how you ask for the next page, which one filtering and paging model settles. Some answer immediately and some hand back a job to poll, which is what asynchronous processing absorbs. And a single installation will eventually carry a field the shared schema has no name for, which is what reaching past the model is for. None of those three is an industry problem. They arrive whichever page you started on.
An industry page is the buyer, a use case is the workflow
The split is worth knowing before you pick a page. An industry page addresses whoever is building the product and collects the workflows they will run. A use-case page takes one of those workflows and follows it end to end, with the endpoints and the decisions the documentation hands back to you: how an invoice gets created in a customer's system, how a bill and its payment get posted, how tax rates reach the entry that uses them. The industry pages link the ones they depend on rather than repeating them.
Under both sits the same machinery, and it is the part that decides whether the second integration costs what the first one did: one authentication layer across every system, one event shape where a system emits events, and a posture that keeps no copy of your customers' books. If you would rather read what other teams did with it than what we say about it, the case studies are the shorter route.
One thing these pages will not do is guess on your behalf. Where a workflow needs an object the target systems do not expose, the page says so and gives the number rather than describing the gap in softer words. That is deliberate: the people evaluating an integration layer are technical, they find the gap during the review anyway, and the only thing a vague sentence buys is a worse conversation two weeks later. Where you see a count on one of these pages it was measured against the per-system documentation, and where you see no count it is because there is nothing honest to put there yet.
We take the systems off your roadmap, not the product off your team
Every page below draws this line for its own industry. The general version is short enough to state once.
- Auth and tokens per system
- One vocabulary for every object
- The write shape each expects
- Their yearly breaking changes
- Which workflow you automate
- What belongs on the document
- When the transfer happens
- Your customers' own rules
The line sits where it does because of what each side can know. A shared layer can absorb how a system wants to be authorized, what it calls a customer and which identifier says whose books a call belongs to, and it can keep absorbing that when the vendor changes its mind next spring. It cannot know which account your customer books a particular kind of revenue to, and the documentation is explicit that the categorization logic depends on your application. Whichever of the five industries you are in, that half of the work is the half your customers are actually paying you for.