Most companies do not choose to become software integrators. It happens to them. They adopt a hiring tool because they are hiring, a payroll system because they are paying people, a spreadsheet for equity because that is where the cap table started, and an accounting package because they need books. Each tool is reasonable on its own. But the moment there are four of them, the company has quietly taken on a job nobody applied for: keeping four separate databases agreeing with each other. This piece makes the case that the better architecture — for a growing mid-market company — is one database underneath all of it.
The hidden job: being the integration layer
Consider what happens when a company hires someone. In a typical stack, that one event has to be entered, separately, in several places. The applicant tracking system records the hire. Payroll needs the new employee set up to pay them. If the role comes with equity, the cap table or ESOP tool needs a grant. And accounting needs to recognise the new payroll cost. Four systems, one event, four manual entries — or four integrations that have to be built and maintained to move the data between them.
This is the integration layer, and in most companies it is staffed by people, not software. Someone re-keys the new hire into payroll. Someone updates the equity spreadsheet. Someone makes sure the accounting reflects the new cost. The company has become the connective tissue between its own tools, and that work is invisible until you add it up.
Why integrations don't actually solve it
The standard answer to fragmented tools is integration — connect them with APIs, sync jobs, and middleware so the data flows automatically. This helps, but it does not eliminate the underlying problem, and it introduces problems of its own.
Integrations move copies of data between systems, which means the same fact now lives in multiple databases and has to be kept in sync. Sync jobs run on schedules, so there is always a window where the systems disagree — payroll has updated but accounting has not yet caught up. Syncs fail, silently sometimes, leaving the systems out of step until someone notices. And every integration is a piece of infrastructure that has to be built, monitored, and maintained, breaking when either system changes. The reconciliation work does not disappear; it moves from manual re-keying to manual checking that the syncs worked. Anyone who has spent a month-end reconciling payroll to the general ledger knows this work intimately.
The deeper issue is that integration treats the symptom. The problem is not that the tools are poorly connected; it is that the same information is stored in several separate databases in the first place. Integration manages that fragmentation. It does not remove it.
What one database changes
Now consider the alternative architecture: a single database underneath hiring, payroll, equity, and accounting. Not four systems connected by integrations, but one schema where each of these is a different view onto the same underlying data.
In this architecture, hiring someone is a single transaction. The employee exists once. Payroll reads the same employee record the ATS created — there is nothing to sync, because there is no second copy. An equity grant references the same employee. The accounting entry for the payroll cost is generated from the same data that produced the payroll. Because there is one copy of each fact, there is nothing to reconcile — reconciliation is the work of making separate copies agree, and there are no separate copies.
This is not a small efficiency gain. It removes an entire category of work. The re-keying disappears because there is one entry. The sync infrastructure disappears because there is nothing to sync. The reconciliation disappears because there is one source of truth. The data lag disappears because every view reads the same live data. The class of errors that comes from systems disagreeing simply cannot occur, because there is only one system.
The trace that becomes possible
There is a further benefit that is easy to miss. When everything shares one database, every financial number can be traced back to the event that caused it. A figure in the accounting ledger can be traced to the payroll run that produced it, which traces to the employees who were paid, which traces to the hires that created them. The chain is unbroken because it is all the same data.
In a fragmented stack, this trace is severed at every integration boundary. The number in accounting came from a sync from payroll, which got its data from somewhere else, and reconstructing the full chain means stitching together records across systems. The single-database architecture makes the provenance of every number inherent — you can always answer "where did this come from?" because it never left the building.
The honest counterargument
The case for best-of-breed tools — separate, specialised systems for each function — is real and worth stating. Specialised tools can be deeper in their domain than any single platform, a company can pick the best tool for each job, and switching one tool does not mean replacing everything. These are genuine advantages, and for some companies, particularly very large ones with the resources to maintain sophisticated integration, best-of-breed is the right choice.
But for a mid-market company — large enough to feel the reconciliation pain, not so large as to have a dedicated team maintaining integrations — the calculus often favours the single database. The depth advantage of best-of-breed tools matters less when the functions are tightly coupled (and hiring, payroll, equity, and accounting are tightly coupled — they are all about the same people and the same money). And the integration burden that best-of-breed requires is precisely the burden the single database removes. The question is whether the marginal depth of separate tools is worth the reconciliation tax they impose, and for many mid-market companies the answer is no.
What this looks like in practice
A company on a single-database platform experiences the difference most clearly at month-end. There is no payroll-to-accounting reconciliation, because the accounting entries came from the payroll data directly. There is no scramble to make the equity spreadsheet agree with the cap table, because they are the same thing. There is no data lag between when something happens in HR and when finance sees it. The month-end that is a multi-day reconciliation exercise in a fragmented stack becomes, in a unified one, largely a matter of review.
This is the architecture behind Helion — hiring, payroll, ESOP, and accounting on one schema, not connectors, not sync jobs. The thesis is simple: a company should not have to be the integration layer between its own tools, and the way to free it from that job is to stop storing the same information in separate places. One database is not just a technical choice; it is what lets a company's people focus on the business instead of on making their software agree with itself.
The companies that feel this most are the ones in the mid-market — past the point where a few spreadsheets suffice, not yet at the scale where a dedicated systems team makes fragmentation manageable. For them, the reconciliation tax is a real and growing drag, and the single database is the architecture that removes it.
This is an opinion piece on software architecture for HR and finance systems, reflecting the perspective behind Helion. It is intended to inform how companies think about their tooling, not as a prescription for any specific situation.