Operations7 min read

Compliance Reporting Without the Quarterly Scramble

A compliance team at a 200-person logistics company in Dubai spent 160 person-days per year on quarterly reporting. Four people, 10 days each, four quarters. Not slow — highly skilled. The data lived in five systems, reconciliation logic lived in spreadsheets, and the audit trail was reconstructed after the fact every single time.

The first question we asked was what was taking so long. The answer was not complicated: the data was not structured for reporting. It was structured for operations. Every quarter, the compliance team assembled a picture that the systems were never designed to produce — pulling transaction records from the TMS, cross-referencing against the ERP, matching to the document management system, and then filling gaps manually from email threads.

The second question was harder: why was it structured this way? The answer is that it always had been. The systems were designed to run operations, and reporting was an afterthought that someone solved with spreadsheets eight years ago. Nobody had made a deliberate choice to structure data retrospectively. It had just happened.

160person-days per year spent assembling compliance reports in one 200-person company — the same data, structured at creation, would have made that 8

The root cause: data structured retrospectively

The quarterly scramble is not a staffing problem. It is a data architecture problem. Compliance reporting is slow when the data is structured at the point of use — the quarterly report — rather than at the point of creation — the transaction itself.

What structured-at-creation looks like in practice: transactions tagged with compliance-relevant metadata when they happen. Cost center. Regulatory category. Approval chain reference. Document ID. The person creating the transaction knows this information. They are unlikely to remember it three months later when the compliance team calls asking for it.

This takes discipline at data entry — and sometimes a small increase in transaction processing time. The payoff is that the reconstruction phase, which is what the 160 person-days was buying, largely disappears. The report becomes a query, not a project.

The audit trail that writes itself

One of the most useful infrastructure changes we have made in multiple operations engagements: append-only event tables for every entity that will ever be audited. Not status columns that get updated. Event streams where every state change is recorded immutably with who changed it, when, and what the entity looked like before.

When an auditor asks "what was the approval chain for PO-4471?", the answer is a single query. Not a reconstruction. Not calls to three people who might remember. A query.

For the logistics client, the change was significant. Before: answering an auditor question required four to six hours of manual reconstruction. After: most questions answered in under 15 minutes. The same data. Different structure.

Our take

The append-only event table is the single highest-leverage infrastructure change for compliance-heavy operations. It costs almost nothing to implement on new systems and pays for itself the first time an auditor asks a question you can answer in 15 minutes instead of a day.

Automation that works even on messy data

Retrofitting structure onto existing data is harder than designing for it from the start. But it is not impossible — and for most companies, there is a large volume of existing unstructured transaction history that cannot simply be ignored.

The approach we use: classification models to retroactively tag existing records based on description text and transaction patterns. Reconciliation scripts that identify records missing required compliance fields. Exception queues that surface unresolvable items for human review, rather than failing silently or making assumptions.

The exception queue design matters. A system that silently skips hard cases is not a compliance tool — it is a compliance liability. Every unresolvable item needs to go somewhere visible, with enough context for a human to resolve it. The goal is not to automate compliance. It is to automate the easy 80% and surface the hard 20% cleanly.

What to actually measure

Three metrics we track for compliance-heavy clients. First: time from quarter close to report submission. The target is under 3 days. Most companies we encounter are at 10 or more. The gap between 3 and 10 is entirely data architecture.

Second: exception rate — the percentage of transactions requiring manual review during report assembly. A well-structured system should be under 5%. If it is 30%, the tagging discipline at transaction time is not holding and the problem is upstream.

Third: audit readiness score — can you answer an auditor question within 4 hours? This is a binary self-assessment across 10 common auditor question types. Most companies, before they fix the architecture, score between 3 and 6 out of 10. The target is 9 or 10.

Most compliance teams are doing monthly and quarterly data cleanup that should have happened at transaction time. Every hour spent cleaning up old data is two hours that could have been saved by designing for auditability from the start. The scramble is not inevitable — it is designed in.