The filing that requires data nobody keeps in the right format

‍

Every regulatory filing starts the same way. A deadline approaches. The filing requires transactional data categorized according to the regulator's definitions. The company's data is organized according to the ERP's definitions, which are not the same.

Sales tax nexus analysis requires revenue broken down by jurisdiction, including states where the company may have created nexus through remote sales, marketplace activity, or temporary physical presence. The ERP records revenue by customer, not by the customer's delivery address or the transaction's nexus-triggering characteristics.

Customs classification requires import transactions categorized by Harmonized Tariff Schedule codes. The ERP records purchases by vendor, part number, and dollar amount. The HTS code, which determines the applicable duty rate, is either buried in a customs broker's entry summary or not in the company's systems at all.

Industry-specific reporting, FDA facility registrations, EPA emissions reports, OSHA injury logs, DOT hazardous materials disclosures, requires operational data mapped to regulatory categories that rarely match how the business tracks that data internally.

In each case, the work is the same. Someone pulls transactional data from the ERP or other systems, manually categorizes it according to the regulatory framework, cross-references against prior filings for consistency, and produces the submission. The categorization logic is specific and rule-based: this transaction type goes in this reporting category, that threshold triggers this disclosure, these exemptions apply to this subset of transactions. The rules are knowable. Applying them to thousands of transactions is where the time goes.

‍

Why data prep for regulatory filings is consistently painful

‍

The friction is not in understanding the regulations. The compliance team knows the rules. The friction is in translating between two incompatible classification systems: the regulator's taxonomy and the company's data model.

‍

Regulatory categories do not map to ERP fields

A sales tax filing requires revenue by state, by tax jurisdiction within that state, by product taxability category, and by exemption status. The ERP records revenue by customer account, by product SKU, by invoice date. The ship-to address, which determines jurisdiction, is on the order but may not be in the revenue report. The product taxability category, which determines whether the item is taxable, exempt, or subject to a reduced rate, is not an ERP field at all. It is a classification that exists in the sales tax engine or in the compliance team's mapping table.

Every filing has a version of this translation problem. The data the regulator wants exists in the company's systems, but it requires combining fields from multiple tables, applying classification rules that are external to the ERP, and handling the exceptions where the standard mapping does not apply.

Prior period filings create consistency requirements

A regulatory filing is not independent of prior filings. The way a transaction was categorized last quarter should be consistent with how it is categorized this quarter, unless there was a legitimate change in the regulatory framework or the nature of the transaction. When a new analyst prepares the filing, they need to understand not just the current rules but the classification decisions that were made previously.

This institutional knowledge typically exists in the prior filing workpapers, which are spreadsheets with formulas, manual overrides, and notes that explain why a particular transaction was categorized differently from the default rule. Recreating the logic from workpapers is possible but slow.

Thresholds and triggers are buried in the data

Regulatory filings are not just categorization exercises. They involve thresholds that trigger reporting obligations. A state sales tax nexus analysis requires tracking whether cumulative sales into a state have crossed the economic nexus threshold, which varies by state: $100,000 in some, $500,000 in others, with some states counting transaction volume separately from dollar volume.

Customs duty calculations depend on classification, country of origin, trade agreement eligibility, and whether any duty drawback or foreign trade zone benefits apply. Each of these is a conditional rule applied at the transaction level that produces a different duty rate.

The compliance team tracks these thresholds, but the tracking requires aggregating transaction data against jurisdiction-specific rules that change periodically. A state that adopted marketplace facilitator rules last year now excludes certain transactions from the nexus calculation. A tariff rate changed mid-quarter, requiring transactions to be split at the effective date.

Multiple data sources, no single report

Most filings require data from more than one system. Sales tax nexus analysis needs revenue data from the ERP, ship-to addresses from the order management system, and marketplace sales from each marketplace platform's reporting portal. Customs filings need purchase orders, customs broker entry summaries, and commercial invoices. EPA reporting needs production data from the manufacturing system, material usage from the bill of materials, and emissions factors from engineering.

The compliance analyst's first task is always the same: export data from multiple systems, normalize the formats, and link the records. This data assembly step can consume more time than the categorization itself.

The filing deadline compresses everything

Regulatory filings have fixed deadlines. A sales tax return is due on the 20th of the following month. An annual customs entry summary is due by the filing date. An EPA report has a submission window.

The work expands to fill the available time, which means the data prep, categorization, and review are compressed into the final days before the deadline. Errors found during review require rework under time pressure. Questions about edge cases are resolved quickly rather than thoroughly. The filing gets submitted, and the workpapers are archived until the next period.

‍

What regulatory filing data prep needs to accomplish

‍

Regardless of the specific filing type, the data preparation follows a consistent pattern: extract, classify, aggregate, and reconcile.

‍

1. Transaction extraction and normalization

Pull the relevant transactions from each source system and normalize them into a consistent format. Revenue transactions from the ERP, marketplace transactions from third-party reports, import entries from the customs broker. Standardize the date formats, currency, entity identifiers, and product references so that classification rules can be applied uniformly.

2. Regulatory classification

Apply the regulator's categorization framework to each transaction. For sales tax: assign the taxability category, the jurisdiction, and the exemption status. For customs: assign the HTS code, determine country of origin, check trade agreement eligibility. For industry-specific reporting: map the transaction to the regulatory reporting category (emission source, waste stream, product registration category).

This step is where the rule-based logic applies. The rules are documented in the regulatory framework and the company's prior filing workpapers. The challenge is applying them consistently to every transaction, not just the ones that are obviously classifiable.

3. Threshold and trigger evaluation

Aggregate the classified transactions against the applicable thresholds. Has the company crossed the nexus threshold in any new states? Have import volumes triggered a duty rate change? Have production quantities triggered a new reporting obligation?

Threshold evaluation catches the compliance risks that are invisible at the transaction level. A single $12,000 sale into a new state is unremarkable. But if cumulative sales into that state have now reached $98,000, the company is $2,000 from triggering a nexus obligation that requires registering, collecting, and remitting sales tax.

4. Prior period reconciliation

Compare the current period's classifications against prior filings. Flag any transactions where the categorization changed from the prior period. Identify new categories that were not present in prior filings. Reconcile the current period's totals against the prior period to produce an explainable variance.

This step catches inconsistencies that would draw regulatory scrutiny. A category that reported $2 million last year and $200,000 this year without explanation will likely trigger questions.

5. Filing assembly

Organize the classified, aggregated data into the format the regulator requires. Some filings accept structured electronic submissions (EDI, XML). Some require specific form formats. Some accept spreadsheets with prescribed column layouts. The output should match the submission format so that the compliance team can review and submit without manual reformatting.

‍

From assembling the filing to reviewing it

‍

The time-consuming portion of regulatory filing data prep is the extraction, normalization, and classification of thousands of transactions against a regulatory framework. The valuable portion is the review: the compliance team confirming that classifications are correct, thresholds are properly identified, and the filing is consistent with prior periods.

The Agent handles the data prep. Upload the transaction data exports (ERP revenue reports, customs broker entry summaries, marketplace sales reports), the regulatory framework documentation (nexus rules, HTS classification guides, reporting category definitions), and optionally the prior period filing workpapers. Describe what the data prep should produce:

"Extract and normalize the transaction data from all sources. Classify each transaction according to the regulatory framework. Aggregate by the required reporting categories. Flag any new threshold crossings. Reconcile against prior period filings and flag classification changes. Produce the filing data in the required submission format with a supporting workpaper that shows the classification logic for each transaction."

The output is the filing-ready data organized by regulatory category, a threshold analysis showing which obligations have been triggered or are approaching, a reconciliation against prior periods with variance explanations, and a classification workpaper documenting the rule applied to each transaction. The compliance team reviews the output, resolves any flagged edge cases, and submits.

The Agent works with the files the team already has: ERP exports, broker reports, marketplace data dumps, prior period workpapers. No system integration or regulatory software implementation required.

‍

What the numbers look like

‍

A mid-market manufacturer with operations in 28 states, importing components from 6 countries, and subject to EPA reporting for 2 manufacturing facilities.

Before: Sales tax nexus analysis takes the tax team three to four days per quarter, pulling revenue data by ship-to state, classifying products by taxability, and aggregating against each state's nexus threshold. Customs duty reconciliation takes two days per quarter, matching entry summaries against purchase orders and verifying HTS classifications. EPA reporting takes a full week annually, extracting production data, mapping to emission factors, and assembling the submission. Total: approximately 40 working days per year on filing data prep across all regulatory obligations.

After: Transaction data from all sources classified against the applicable regulatory framework. Sales tax nexus analysis identifies 2 states approaching the economic nexus threshold (within $15,000 of triggering) and flags 47 transactions where the product taxability classification differs from the prior period. Customs duty reconciliation surfaces 8 entries where the applied HTS code produces a different duty rate than the broker's classification, representing $34,000 in potential duty savings. EPA reporting data is assembled with each emission source mapped to the corresponding production data and emission factor, with 3 categories showing year-over-year changes that require narrative explanation. The compliance team reviews and finalizes each filing in one to two days instead of three to seven.

The specifics shift by filing type:

• In sales tax, economic nexus rules vary by state and change frequently. A company selling into 45 states needs to track revenue and transaction count against 45 different threshold combinations, some with annual reset dates, others with rolling 12-month windows. The data prep includes not just current period classification but retroactive analysis of when nexus was triggered.
• In customs, HTS classification is both technical and consequential. A component classified under one heading may carry a 2.5% duty rate; under a slightly different heading, it may be 8% or eligible for a free trade agreement rate of zero. The classification depends on the component's material composition, function, and end use, none of which are standard ERP fields.
• In environmental reporting, the connection between production data and reportable emissions runs through emission factors that may be facility-specific, equipment-specific, or based on industry averages. The data prep requires linking production quantities to the correct emission calculation methodology for each reportable pollutant at each facility.

Every classification, threshold calculation, and prior period comparison is documented. When the regulator asks why a transaction was categorized in a particular way, the supporting logic is already in the workpaper.

‍

Compliance risk lives in the data prep, not the filing

Companies rarely get regulatory filings wrong because they misunderstand the rules. They get them wrong because the translation from transactional data to regulatory categories is time-consuming, manual, and dependent on one person's knowledge of both the company's data and the regulatory framework.

The filing itself is the final step. The risk is in the 90% of the work that precedes it: pulling data from multiple systems, classifying thousands of transactions against rules that do not match the ERP's structure, tracking thresholds across jurisdictions, and maintaining consistency with prior periods. When that data prep runs systematically against every transaction, every rule, every threshold, the compliance team's time shifts from building the filing to reviewing it.

‍