Data foundations before AI: the fixes that pay back within two quarters

Most AI plans assume the company's data is ready and that the work lies in choosing a model. In established businesses the data is usually in the right systems and in the wrong shape: the same customer held three ways, product codes that mean different things in the store and the warehouse, revenue that differs between the analytics property and the ledger.

The fastest way to find what needs fixing is to follow real records. Take a sample of orders, invoices and stock movements and trace each one through every system that touches it, from the store or quoting tool through the payment provider, CRM and warehouse to the accounting package and the reporting layer. Note where the record is rekeyed by hand, where a spreadsheet copies it, where its identifier changes and where it disappears. Those points are the backlog.

The fixes below are the ones we expect to pay back within two quarters. Each removes manual work or a reporting error that already costs money, and each is a prerequisite for any AI feature that will later read the same records.

Every downstream use depends on joins. Revenue by customer needs the order system and the ledger to share a customer key. Margin by product needs the store, the warehouse and the purchase ledger to agree on what a product code means. An AI assistant that answers questions about orders or products inherits whatever ambiguity the keys carry.

The check is quick to run. For each identifier, test that it is populated and that it is unique across the whole population, so that one code means one product. Those are separate tests. A product code field can be filled on every record and still be shared by two different items, which is enough for an assistant to describe the wrong product with full confidence, or for a catalogue sent to a trade partner to quote the wrong item under the right code.

The payback comes from the work the fix removes: credit notes for wrong shipments, hours spent reconciling customer statements, and reports rebuilt by hand each month because two systems disagree.

Google Analytics 4 standard properties keep user-level and event-level data for 2 months by default and 14 months at most; longer retention for event data is available only on the paid 360 tier. Standard reports run on aggregated tables and keep showing older totals, so the loss stays invisible until someone builds a year-on-year exploration or funnel and finds the earlier period empty. Raising the retention setting protects only data that has not yet been deleted.

The durable fix is the BigQuery export, which copies raw events into a warehouse the business owns. Standard properties can send up to 1 million events a day through the daily export. The streaming export has no volume limit and costs $0.05 per gigabyte, which Google puts at roughly 600,000 events. At those rates the storage bill for a mid-sized business is small next to the cost of planning a peak season without last year's behavioural data.

This fix has its deadline built in. Every month it waits is a month of event history that cannot be recovered, and the 2027 planning cycle will want the 2026 peak season in full.

Electronic invoicing turns customer master data into a compliance dependency. In Germany, businesses whose prior-year turnover exceeded €800,000 must issue domestic business-to-business invoices in a structured electronic format from 1 January 2027, with all other businesses following from 1 January 2028; receiving them has been mandatory since 1 January 2025. In the UK the government has said that all VAT invoices will have to be electronic from April 2029, has confirmed Peppol as the exchange network, and said a detailed implementation roadmap would come with Budget 2026, due on 28 October.

The work that pays back is the same in both countries and starts well before any deadline. Complete and validate customer VAT identifiers, tax numbers and electronic routing addresses on the customer master. Standardise product and tax codes on invoice lines. Remove the manual steps between the order system and the invoice. A rejected invoice delays cash, so clean master data shortens collection as well as meeting the rule, and a data model built for a German entity this quarter can be reused for the UK later.

The last fix is a discipline more than a system. Management reports take revenue from the store or CRM, costs from the ledger and marketing results from the advertising platforms, and the three rarely agree. When the board pack and the accounts differ by an amount nobody can explain, every figure in the pack loses authority, and decisions slow while people argue about which number is right.

A monthly bridge settles it. After close, each headline figure in the management pack is reconciled to the ledger, with the difference broken into named, recurring items: timing, refunds, tax, intercompany, test orders. The bridge is generated from the systems rather than assembled by hand, and any unexplained residual above an agreed threshold is investigated before the pack goes out. Once the recurring items have names, what remains is usually a short list of processes nobody had documented.

This is also the foundation any AI reporting assistant will need. A model asked why margin fell in a region can answer correctly only if the figures it reads have already been reconciled. We build these bridges from the ledger outward for the same reason we start every engagement from orders, ledgers and logs: the dashboard is only as good as the records beneath it.

In November 2026, trace a sample of real orders, invoices and stock movements through every system and list each point where a record is rekeyed, copied or given a new identifier.

Before the end of November, set GA4 event retention to 14 months on every property and link each property to BigQuery, so that the 2026 peak season is kept in full.

By the end of December, run uniqueness and completeness checks on customer, product and order identifiers across systems, and fix duplicate product codes before any AI feature or trade catalogue relies on them.

For any German entity, confirm before 1 January 2027 whether it is above the €800,000 threshold and that its invoicing and customer master data are ready, and plan the UK mandate on the same data model once the roadmap is published.

From the January 2027 close, publish a monthly bridge from the management pack to the ledger, with named reconciling items and a residual threshold.

By June 2027, choose the first AI use case from the reconciled data and measure its baseline from the same records.