Case studies from teams that went to market faster.
Accounts payable, time tracking, debt collection, fleet management, CRM: very different products, with very different use cases, all reaching the ERP and accounting systems their customers run through the same integration layer.
Software teams that grow with Maesn
Eleven are written up in full. Under each name is what that company does, which use cases it runs and which of its systems the integration reaches.
Cash Flow ManagementReads the ledger through Maesn and keeps the bank side on its own connection, then writes the reconciled bookings back.Read the case study
- The challenge
- what the product could not do while the connection was manual
- The solution
- which objects move in which direction, and where they land
- Systems
- the ERP and accounting systems that customer went live with first
- Endpoints
- the calls the integration makes, where that customer names them
From isolated processes to one integrated path
Every one of these studies describes the same starting point in its own words: a manual step between the product and the system its customers keep their books in.
- CSV exports and imports, moved by hand between the product and the customer's ledger
- A handful of integrations built in-house, each with its own authentication and data model
- Every new market or system starting again as its own project
- Product data and accounting data living in separate places, and meeting only when somebody moves them
- Maintenance competing with the roadmap, and winning more often than planned
- One connection, and every supported ERP and accounting system behind it
- One data model for invoices, contacts, ledgers and payments, whichever system they came from
- A new system as a configuration step rather than an integration project
- The customer's ledger reachable from inside the product, without an export in between
- Upstream API changes absorbed on Maesn's side
The manual step works while there is one customer and one system, which is why it survives so long. It becomes expensive at the second: customers run whatever their market runs, and in Europe that means a different accounting system per country and often per industry. The effort does not scale with the size of your team, it scales with the number of systems your customers use.
Work that repeats, and work that happens once
Each of the nine connected once, to the same API and the same data model. What differs between them is which systems their customers asked for, not what they had to build.
- Authentication per system, from API keys to OAuth to two-factor and multi-company flows
- One data model for invoices, contacts, ledgers and payments, whichever system they came from
- Pagination, filtering and error semantics normalised across every connected system
- The local product knowledge each system demands, which is where DATEV cost Tipalti its business case
- Maintenance when an underlying API changes its fields, formats or endpoints, absorbed on Maesn's side
- Every system added after you integrate, available on the interface you already built against
- What your product does with the data once it arrives
- Which systems your market asks for first, and in what order you roll them out
- The commercial value of the coverage, which is different in every category
- Whether integrations are a support cost or a growth channel, which is a positioning decision
The difference shows in how differently they use it. Tipalti reads suppliers, accounts and tax rates and posts bills and documents into the ledger, starting in the Netherlands with Exact Online and expanding into DACH with DATEV Rechnungswesen and Dynamics 365 Business Central. Paywise reads the other way, pulling overdue invoices out of systems like sevdesk. Clockin writes, creating draft invoices into Sage, and Rally replaced a direct DATEV build with a REST API and a sandbox. All of it rests on the same common data model and the same unified authentication, and every other system in the integrations directory sits behind the connection they already built.
Suppliers, ledger accounts and tax rates come in so a bill can be booked correctly, then the bill and its document go back into the customer's own ERP system.
- Get Suppliers
- Get Accounts
- Get Tax Rates
- Post Bill
- Post Document
Customers and suppliers come in so tracked project time can be matched to the right party, then the draft invoice is written into the accounting system.
- Get Customers
- Get Suppliers
- Post Invoice
Integrations as a commercial argument
These results are not engineering metrics. Where there is a number on the change, the number is about how the product sells.
- inbound leads for Clockin in two weeks
- 800+inbound leads for Clockin in two weeks
- sprint to implement Paywise's integration
- < 1sprint to implement Paywise's integration
- European regions Tipalti rolled out across
- 2European regions Tipalti rolled out across
Three figures for nine customers. The others describe what changed without putting a number on it, and none is invented here to even out the row.
Clockin's figure is the clearest sign that integration coverage is a go-to-market asset rather than a support cost, and what it connected is a small surface: invoice creation from project data. Paywise reports the same effect from the adoption side, on debt collection, where the value depends entirely on whether the open items arrive without an upload. Tipalti frames its result as market access, because accounts payable automation only pays off when bookings land in the customer's own ERP system. HubSpot puts no figure on it, and what it does state is the scope: customer and supplier data sync between the CRM and the DACH accounting systems its customers run, instead of an import by hand.