top of page

Data is the Foundation of Finance: Even in the age of AI, Data is King

One of the most important lessons I’ve learned at the intersection of finance and AI is that data quality isn’t a new problem and it isn’t an AI problem. It’s a design problem. Long before machine learning models or even spreadsheets existed, financial teams understood that consistency and structure in data were essential. AI can't work without good data and those companies who have good data will be able to leverage AI.


A Finance data pyramid design from the bottom up.

From Order to Chaos — and Back

When a business is small, building and maintaining robust data systems can feel unnecessary. Everything fits in a spreadsheet or two. But as an organization grows, the equation flips: operating without a unified system consumes more time, introduces more errors, and compounds inefficiencies across every department.


Eventually a company needs to adopt an ERP or accounting system and that's when it will need to design it data. Preferably from the bottom up.


Step One: Speak the Same Language

Before you can trust your data, you have to standardize your vocabulary.

Do you call them customers or clients? If a customer has multiple subsidiaries, do they count as one entity or several? When tracking sales by region, do you use the billing address or shipping address? Are commissions assigned to sales people or sales teams?

These seem like small or semantic choices, but they are the bedrock of any reporting structure. Tiny inconsistencies here can create major data headaches later.


Step Two: Build Clean Intake Points

Every data journey begins with onboarding customers, vendors, and employees. This is where you define the fields, categories, and metrics that matter most. From there, you move to the chart of accounts the heart of finance reporting function.

Once transactions start populating those accounts, change becomes painful and costly. If you operate multiple entities, uniform general ledger accounts across all subsidiaries are really helpful. And above all, limit who can create new accounts otherwise, uncertainty breeds chaos and any bookkeeper will add new GL accounts that will pollute your data.


Step Three: Real-Time, Reliable Recording

Once your framework is in place, the real work begins recording financial activity through the standard cycles:

  • Sales to cash (A/R)

  • Purchase to payment (A/P)

  • Payroll, fixed assets, and others

The quality of data entry defines the reliability of reporting. Real-time bookkeeping isn’t just a convenience; it’s a control that prevents mistakes and highlights issues well before the monthly close. Poor and late data entry leads to poor reports and the cost of cleaning up bad data multiplies over time.

With consistent real time intake and disciplined entry, monthly closes and cashflow analyses become easier, faster, and more accurate.


Step Four: Build for Change, Not Rework

Enterprises evolve. Metrics change. But if your data design is sound, you can add new metrics without breaking what already exists. You can modify intake forms to start collecting new data points though no design can retroactively create information that wasn’t captured in the first place (you can do update projects of course). Once the fields are added in a couple of months you start getting good and reliable data.


Good data flows from the bottom up to the report, never the other way around (meaning that the new report we want organizes the data below).


Centralization vs. Fragmentation

Ideally, all of this happens in a single ERP system (I'm biased towards Netsuite) with one version of the truth that enforces your nomenclature and process discipline.


But even if that’s not possible, the underlying logic still applies. What matters most is that your company's “source of truth” is well-defined and universally respected.


Many companies I've seen grew up in waves and opted for short term patchworks of poorly connected systems. These specialized departmental systems (CRM, HR, procurement) offer rich functionality and features but enterprises don't realize is that it comes at the price of data quality and consistency. It’s the classic tradeoff: features versus data quality. Sometimes it's by design (usually promoted by department heads that want their own software and features) and sometimes it evolved organically (each new needs brings with it new software).


Tradeoff between good data and department focused Saas.

The results are often the same:

  • Customer onboarding lives in Salesforce or Hubspot (with parent/sub relationships your ERP can’t recognize).

  • Vendor onboarding happens in Tipalti or some other platform, with currencies your finance cycle doesn’t support.

  • Employee data sits in HiBob, while expense reports and payroll live elsewhere entirely.

  • And this is without considering additional complications such as multi-national companies.


The finance team ends up as a guest on everyone else’s platform, reconciling data sets in cross departmental Excels held together by human tears and VLOOKUPs. Every cross-system report means three reconciliations and four versions of “final.xlsx.”


More mature organizations often turn to APIs to connect systems and enforce naming conventions and streamlined workflows. APIs help but they require maintenance and governance. Each connection is another potential failure point.


Finance data illustration of "patches" style companies that emphasized department specific saas.

The Immutable Rule: Garbage In, Garbage Out

No system, not even AI, can fix bad data. A model can’t “un-garbage” what it receives.

That’s why companies seeking to harness AI must first confront a simple truth: the future of finance automation depends on the oldest principle in accounting: structured, consistent data.


The Takeaway

The finance teams that will benefit most from AI aren’t those buying the most tools, they’re the ones who’ve designed their data strategy from the ground up:

  • Uniform definitions

  • Controlled intake points

  • Centralized systems

  • Real-time, disciplined entry

Because when your foundation is solid, AI becomes a multiplier.When it’s not, it just becomes another patch.


bottom of page