Your Data Isn't Dirty. It's Unexamined.

Your CRM holds one count of your customers. Your accounting tool holds another. Your inbox holds a third. None of them agree, and you have never had a reason to care until the moment you try to feed any of them into an AI tool and watch it produce something confidently wrong.

That moment is not a data problem. It is a visibility problem. The data was always like this. The AI just made the disorder expensive.

The audit most founders skip isn't optional anymore

A 2023 Forrester survey of 320 small and medium business decision-makers, commissioned by AWS, found that the right posture for small firms approaching data and AI is agile, use-case-specific, and incremental. Not comprehensive. Not consultant-led. The recommendation is to start with one high-value use case and build from there. That finding matters because it reframes the question. You are not trying to fix all your data. You are trying to determine whether one specific slice of it is fit for one specific purpose.

The distinction changes what six to eight weeks of work looks like entirely.

What the audit actually produces

The output of a useful data audit is not a report. It is a column-level issue log: a row for each field in each data set you plan to use, with four entries per row. What type of data lives in this column. What percentage of rows are missing a value. What formatting inconsistencies exist. Whether the values look plausible given what you know about your business.

Quadratic's audit workflow makes this separation explicit: document every problem before touching anything. The audit phase and the fix phase are separate. Founders who skip straight to fixing tend to fix the wrong things first, because the most visible problems are rarely the ones blocking the AI use case.

A column-level log forces a different kind of decision. For each issue you find, you assign one of two labels: fix before the pilot, or defer. That is the only output that matters. A general impression that your data is "pretty good" or "a bit messy" tells you nothing about whether a specific tool will work on it.

The objection worth taking seriously

The strongest argument against a self-directed audit is not that founders lack time. It is that founders lack the background to know what they are not seeing.

ICAEW's spreadsheet review guidance describes a five-stage process. The structural review and detailed review stages exist specifically to catch what a column-level scan misses: formula logic pulling from the wrong cell for two years, hidden dependencies between sheets, errors that look valid because they are internally consistent but factually wrong. A founder checking for blank cells and formatting problems will not find those. The SB-DQMM-SPG dissertation, which built a four-level data quality maturity model for small businesses, places a basic data inventory at Level 1 of four. Stopping at Level 1 and calling the business AI-ready is, in that framework, a category error.

This objection is correct on the narrow technical point and wrong on the practical one.

The maturity model and the ICAEW five-stage review are designed for ongoing governance programs, not for answering a single scoped question. The SME quandary paper found that data governance frameworks systematically fail small businesses by assuming organizational capacity those firms do not possess. A five-stage spreadsheet review assumes a reviewer with auditing competency. Most founders do not have that, which is exactly why the frameworks have not reached them. The SB-DQMM-SPG dissertation documents that most small businesses operate with no data inventory, no stewardship roles, and no quality controls at all. A column-level issue log with fix-or-defer criteria is not a substitute for Level 4 maturity. It is what moves a firm off Level 0.

The audit does not claim to catch everything. It claims to catch what blocks the specific use case. That is a narrower claim, and it holds.

Where to start, concretely

Pull your customer records into a spreadsheet. Create one row per column in your data set. For each column, record the data type, count the blank rows, note any formatting inconsistencies, and flag any values that look implausible. Do this before you touch anything. Do not clean as you go.

Do the same for the financial data fields your AI use case will touch. If you plan to use an AI tool for invoice categorization, you need the transaction description field, the amount field, and the category field. Not your entire chart of accounts. Three fields. The quantitative accounting study drawing on 220 responses from owners, accountants, and finance officers found that cloud-based integrated accounting systems associate with significantly lower financial error rates compared to manual systems, with internal control integration and automation as the strongest predictors. If your financial data lives in a manual spreadsheet, that finding is a direct argument for moving it to a cloud accounting tool before running the pilot, not after.

Operational logs follow the same pattern. Identify the specific log your AI use case reads. Pull a sample. Run the same column-level check.

At the end of six to eight weeks, you have a document with every data field your pilot needs, a description of every quality problem in each field, and a fix-or-defer label on each one. That document answers a question most founders never ask explicitly: is this data set fit for this specific purpose, and if not, what exactly is wrong with it.

The answer is almost never "everything." It is usually two or three fields with specific, fixable problems and one field you need to defer or exclude from the pilot scope entirely.

That is enough to start.