Financial work is a systems problem - SecondState

Exec Sum<br>Deal-side finance teams repeatedly rebuild the same machinery: ingesting, reconciling, and investigating unfamiliar data. SecondState is designed to preserve that machinery without removing the judgment the work depends on.<br>I recently wrapped up my time at a big4 firm, where I worked on tooling and software for finance teams. The better part of it was spent solving problems with big decision trees - problems where rigid, hand-engineered solutions rarely scale.

A surprising amount of deal-side financial work starts with a data room. The finance professional calls the data engineering team - if they are lucky enough to have one - and asks them to turn a pile of files into something usable. Only then can the investigative work begin, usually on top of a static dashboard.

This post goes into the thinking behind SecondState, a workspace for this kind of financial work. That sentence is vague enough to be useless, so let me start with the work itself.

This is also my first blog post. My hope is that it will be informative and fun. If not, I would like to know, although I may take it personally.

Deal work

Company A wants to acquire Company B.

Company B might claim that its revenue is growing, margins are improving, and customers are very happy. They are probably true. But the buyer should probably check before handing over the money.

This is roughly where a financial due diligence (FDD) team comes in. The team looks beneath the financial story of the business. Are the profits real and repeatable, or driven by one-off items? Where does revenue come from, how concentrated is it, and why do customers leave? How much cash does the company need to operate every day? Are there hidden loans, tax exposures, legal costs, or other obligations?

To answer these questions, the team receives things like trial balances, general ledgers, sales registers, payroll files, management accounts, budgets, contracts, and presentations. The files arrive through a data room, usually with helpful names such as Final_GL_v2_UPDATED.xlsx.

At this point, we should make a distinction: this is not the same as running internal finance operations inside a company.

An internal finance team has a kind of 'memory'. It returns to the same systems every month. It knows the ERP, the chart of accounts, and where the quirks usually come from. A diligence team arrives cold and needs time to understand how the client operates.

The loop underneath the work

On paper, the work can be drawn as a DAG (directed acyclic graph): data comes in, a set of policies and coherence checks are applied, transformations gets applied, and you get clean data as output - ready to be served to the finance team through a dashboard, that is usually static.

The policies & coherence checks are usually straightforward in isolation:

Is the data complete/incomplete?

Does the general ledger reconcile with the trial balance? Are debit and credit signs consistent?

Do the accounts, entities, currencies, and periods map correctly?

Are there duplicates, missing months, or transactions that do not balance? ....

But it rarely goes in a clean and straightforward fashion.

Incompleteness and incoherent mappings leaves deal teams fighting an arms race. A missing period sends the team back to the client. Failed reconciliations creates bottlenecks. Unusual balances opens new multiple investigations. All of this problems occur before the team actually does valuable work, where they have clean data to operate on top of, to trace back to reality all the elements that are claimed in the financial statements and others.

At that point, the graph is no longer much of a graph. It is a loop. You keep looping until you land on one of the final scenarios: everything checks out, or something looks fishy and you let the acquirer know, giving him a much clearer vision of the economics.

Figure 1<br>A failed check sends the engagement back through the same machinery.

Zooming out

A firm does not run this loop once on a unique engagement. It happens across deals, all around the year.

Figure 2<br>The same loop is rebuilt across the firm’s client engagements.

The bigger challenge is how a firm operates the machine behind all of these engagements. not a single engagement in isolation.

Accounting is universal, but unfortunately, every ERP has its own opinionated way of packaging the data. Each deal arrives with a certaiin format. The mappings are rebuilt, the same policies are rewritten, and familiar reconciliation problems are solved all over again on the next deal. The work is documented in a spreadsheet, a SQL script, or inside the head of the person who happened to solve it a year ago. Then the engagement ends, and most of that context disappears.

At this point, it stops being an isolated engagement problem. It becomes a systems problem - and a productivity problem for the entire firm. Finance professionals wait for data teams, data...