SaaS keeps the work, the accounting system takes the invoice

The top of that chart is the paperwork around a transaction and the bottom is the work that produced it. A sales order is defined in the documentation as a basis for generating invoices, an offer as a document a seller gives a buyer, a unit as pieces, kilograms, liters or hours. Those are the objects a vertical platform lives in all day, and they are the ones the accounting systems expose least, because an accounting system is built around the document that creates a financial obligation rather than around the job that led to it.

The useful reading of that chart is not the drop, though. Offers are live at three systems and reachable at twenty-two, which is the same total as customers. What separates the top of the chart from the bottom is not whether the object exists in the model, it is whether it is switched on today. The widest of the systems upstream is Business Central, the one connected system that accepts a written offer today and one of the four that expose sales orders, which is worth knowing if your customers sit at the larger end of the mid-market.

The second half of the problem is arithmetic rather than architecture. Your customers did not pick their accounting system to suit you, and a vertical platform inherits whatever mix its own customer base carries. HubSpot ran into exactly this in the German-speaking market, where a multitude of accounting systems and industry-specific tools made building and updating a connection per system unfeasible even at their scale. Clockin, a much smaller company, reached the same conclusion for the same reason and said so plainly: with that spread of tools in use, building the integrations in-house was unrealistic. The system directory has a country filter, and the useful thing to do with it is to check the spread you have already inherited.

None of them is an accounting product. They track hours, run building sites, manage treatments, schedule shifts, administer properties, handle legal matters and, in three cases, do their own work with a model rather than a form. Every one of them still ends up writing into an accounting system. That is the whole argument for treating this as a platform capability rather than a customer-specific feature: the profession changes completely from one row to the next, and the last step does not change at all.

Two of them have the whole story on record. Clockin is the useful one if you are weighing a build, because its previous solution is stated plainly as manual creation of invoices in the accounting system, which is what the integration replaced. The list is complete rather than curated: it holds every SaaS customer whose category Maesn publishes, in the order the categories happen to fall. A profession that is missing from it is genuinely missing, not left out for space.

The line sits where it does because of what each side can actually 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 doing that when the vendor changes its mind next spring. It cannot know that your customer books maintenance revenue to one account and installation revenue to another. The documentation is explicit that categorization logic depends on your application, and anything that settled it centrally would be inventing an accounting policy for a company it has never seen.

Two neighbouring parts follow the same principle, and both matter more to a vertical platform than the general case suggests. You will have one or two customers whose installation carries a field nobody else asks for, and reaching past the model returns that field without you forking an integration for a single account. Which of your customers, and which of their companies, a call belongs to is settled by one authentication layer, instead of an identifier scheme you would otherwise learn once per vendor. Freshness follows the same shape: ask the GET endpoints what has changed since a timestamp rather than diffing copies, and where a system emits events, webhooks carry the same normalized payload with far less traffic. None of that puts a copy of your customers' books on our side, and the security posture sets out what is kept instead.

If you want the mechanics rather than the argument, the invoice creation guide is the shortest complete example: one required read, three optional ones, your own trigger and the write, with the endpoint behind each step and the point where the documentation hands a decision back to you. Read by role rather than by industry, the same ground is covered for product and engineering teams.