maesn
HERO Software
Field Service

HERO Software raises the invoice where the bookkeeping data already lives.

HERO Software is an end-to-end product for trades businesses: projects, orders, the CRM and the invoicing all happen in one place. That makes it the system where the bookkeeping data is created, and the only question left is whether it survives the trip to whichever accounting system the business keeps.

The integration went smoothly, and the range keeps growing

The support provided is truly first class, with impressively quick response times. The documentation is thorough and easy to follow, which made integration a smooth process for me. I also appreciate the wide range of accounting integrations and endpoints available. It's clear that the endpoints are continuously being developed and expanded, which adds even more value to the platform.
Ricardas Kauneckas
Full Stack Engineer, HERO Software
Key facts

Who HERO is, and what runs on Maesn

Website
hero-software.de
About HERO Software
HERO Software GmbH from Hannover, a cloud product with a companion app for trades businesses of two to fifty employees, across every finishing trade from plumbing and electrical to roofing, joinery and solar. Its own site names Germany, Austria, Switzerland and the Netherlands as its markets, and Maesn publishes 40.000 tradespeople on the platform.
What runs in HERO
Project management, order handling, the CRM, time tracking and the invoicing, including the receivables. The invoice is raised in HERO and sent from HERO.
Use case
Reading the customer master data and posting the booking back once the invoice is out. The workflow itself, independent of any one product, is on the payment reconciliation page.
Accounting systems
DATEV and further accounting systems inside and outside the German-speaking market, on the same connection
The problem

The invoice decides what the booking will look like

A trades business does not do its accounting in the evening. It does it by raising an invoice, and everything a booking later needs is settled in that moment: what was delivered, when, and at which rate.

Because invoicing happens inside HERO Software rather than in a ledger, HERO is where the accounting-grade detail comes into existence. The items and services are already maintained there, the time tracking supplies the period the work fell into, and the invoice carries the rate per line for customers inside and outside Germany. None of that is bookkeeping work in the usual sense, and all of it is what a clean set of books depends on.

The risk is not in getting it right. It is in what happens at the handover, because a booking has to arrive in the shape the receiving system expects, and there is no shared shape: the German market alone offers several, and HERO sells into four markets. Rebuilding that per system, and keeping it rebuilt, is a second product next to the one the trades businesses actually buy.

Articles and servicesThe items and services maintained in HERO, carried straight onto the invoice rather than retyped.
Line items and descriptionsWhat was actually delivered, at the level of detail the customer sees and the bookkeeping needs.
Service periodsWhen the work was performed, which is what decides the period a booking belongs to.
Tax ratesThe rate per line, for German and non-German end customers, and HERO sells into four markets.
Four things a booking needs, all of them settled in HERO before any accounting system sees them.
How Maesn solves it

One posting, and the shape is somebody else's problem

HERO writes the posting once. Whether it lands as a journal entry or as a booking proposal is a property of the system on the other side, and on most systems there is no second option.

10
accept a journal entry

The booking is made, for a business or an advisor who keeps the books themselves.

10
accept a booking proposal

The booking is suggested, and somebody reviews and releases it on the other side.

3
accept either one

Exact Online, Dynamics 365 Business Central and Xero. Everywhere else the shape is fixed for you.

Counted across the 30+ connected systems: 17 take a posting in one shape or the other.

On fourteen of the seventeen there is nothing to choose, so a product that writes postings itself has to know per system which of the two shapes exists, what it is called there and what it demands. The common data model is where that difference is absorbed, so HERO writes one posting and the customer master data comes back in one shape as well.

The other half of the ramp-up is that nobody at HERO is in the room when a connection is switched on. A trades business with four people connects its own accounting system, and it has to work the first time. Unified authentication is the part that carries that, including for the systems where a customer runs more than one company.

What changed

Several hundred connected businesses in the first weeks

HERO Software went from launch to several hundred connected end customers inside the first weeks. That is a self-serve curve rather than a rollout, and it is only available to a product whose customers can switch the connection on themselves.

In the engineer's words

“I also appreciate the wide range of accounting integrations and endpoints available. It's clear that the endpoints are continuously being developed and expanded.”

The range is the part that decides whether the fourth market is a project or a configuration. Of the seventeen systems that take a posting, five belong to the German-speaking market and the rest are spread across the Netherlands, the Nordics, the UK and the global platforms.

HERO publishes Germany, Austria, Switzerland and the Netherlands as its markets, and the Dutch accounting landscape has nothing in common with the German one. What changed is that this stopped being an engineering question: the same posting reaches a Dutch ledger and a German one, and the difference is absorbed before it reaches HERO's code. Reading customer records the other way is the neighbouring workflow on customer and supplier data sync. And since the people who felt this most are the ones who built it, the case for it is laid out for product and engineering teams in their own terms.

HERO Software case study FAQ

Common questions

What does the integration actually move?

Two things in two directions. Customer master data is read out of the accounting system so an invoice is raised against a record that already exists there, and the posting is written back once the invoice is out. The invoice itself never leaves HERO: it is created there, sent from there, and the receivables are managed there.

Journal entry or booking proposal, and who decides?

The target system decides, not HERO and not the customer. Measured across the 30+ connected systems, ten accept a journal entry and ten accept a booking proposal, but only three accept both. For the other fourteen the shape is fixed by the system, which is precisely the kind of difference a product should not have to carry in its own code.

Does this work outside Germany?

That is most of the point. Of the 17 systems that accept a posting, five are products of the German-speaking market and the rest are not: the Netherlands, the Nordics, the UK and the global platforms are all in the same set. HERO publishes Germany, Austria, Switzerland and the Netherlands as its markets, and the connection does not change when a customer's ledger does.

Why does the bookkeeping data have to be right this early?

Because the parts that are hardest to get right are decided while the invoice is being written, not afterwards. The service period, the rate per line, the split between what falls in one period and what falls in the next: all of that exists in HERO at the moment of invoicing. If it arrives flattened, somebody rebuilds it by hand from a document.

How quickly did it ramp up?

Several hundred connected end customers in the first weeks, which is a different curve from a handful of enterprise rollouts. That shape only works if switching a connection on is something the trades business itself can do, without a project on either side.

Can another vertical product use the same setup?

The objects are the same wherever invoicing happens in the product rather than in the ledger: the customer record, the posting and the data that makes the posting correct. What differs is which accounting systems your own customers keep, and that is a coverage question rather than an integration one.
Ship your ERP and accounting integrations. Connect once.
Book a demo