A file can open successfully and still be wrong. Its dates may refer to different timezones, its totals may combine different currencies, or its identifiers may lose meaningful leading zeros. Export validation should therefore cover the contract between producer and consumer, not just whether a serializer completed. Define what the file is supposed to mean, check that the selected data satisfies that meaning, and verify the representation the recipient will actually use.
Turn the report definition into a contract
For each export profile, specify the fields, types, required values, allowed ranges, and cross-field rules. Record the schema version and the intended consumer. A machine import may demand an exact column order and a stable representation of missing values. A human-readable workbook may prioritize labels and clear units. Both need a defined meaning for each column. Avoid generating the schema from whichever record happens to appear first.
Consider a sample order report with order identifier, completed time, amount, currency, and customer reference. The identifier is text even if it contains only digits. The amount needs an agreed decimal representation, and the currency must accompany it. The completed time needs a timezone or a documented UTC convention. A customer reference may be optional, but an empty order identifier makes the record unusable. These are business decisions that should be settled before rendering begins.
Validate the request before reading the dataset
Check that the requested format, columns, sort order, date range, and filters are supported. Confirm that the authenticated requester is allowed to export the selected scope. Apply size and complexity limits before launching expensive work. For example, reject a reversed date range with an actionable message rather than running a query that returns nothing. When a user asks for an unknown column, explain the valid alternatives instead of silently removing it.
Keep parameter validation separate from authorization. A perfectly formed account identifier can still refer to someone else's data. Also distinguish a valid empty result from a malformed query or unavailable source. A report containing zero records can be a legitimate outcome, but the job metadata should state that the query completed successfully. The export workflow quickstart provides a useful place to document those request and result expectations.
Check individual values without changing their meaning
Validate required fields, lengths, numeric ranges, and supported enumerations while preserving meaningful source data. Do not convert a missing number into zero simply because a spreadsheet formula would be easier to write. Do not trim or normalize identifiers unless the contract explicitly allows that transformation. A product code beginning with spaces or zeros may look untidy while still being a valid identifier in the originating system.
Make normalization rules explicit and reversible where practical. A date displayed as day, month, and year should not be guessed from an ambiguous text value. Parse using the source's agreed representation and reject or quarantine values that do not match. Keep the original source reference for investigation without placing the entire sensitive record in logs. A useful validation error identifies the field, rule, and affected record reference with a clear next action.
Validate relationships and totals
Some failures only appear across fields or records. A completed order should not have a completion time earlier than its creation time under the report's business rules. A unique order identifier should not repeat unless the export intentionally contains line items. A totals row should use the same filters and rounding policy as the detail rows. State whether amounts are gross, net, refunded, or outstanding so the consumer can reconcile them correctly.
Aggregate by compatible units. If a dataset contains several currencies, provide separate totals or an explicit conversion method with its own documented inputs. Do not add unlike amounts and label the result revenue. Similarly, keep quantities with different units distinguishable. For a sample inventory export, a quantity of ten cases and a quantity of ten individual units should not become twenty units without a defined conversion.
Choose a deliberate invalid-record policy
Decide whether an invalid record fails the entire job, is excluded with a report, or appears with an explicit warning. The choice depends on the purpose. A reconciliation file may require complete agreement before publication. An exploratory analysis extract may tolerate a documented subset, provided the missing records and their effects are visible. Never silently discard failures just to produce a downloadable file.
| Failure | Possible response | Information to preserve |
|---|---|---|
| Missing primary identifier | Reject or quarantine the record | Source reference and failed rule |
| Unsupported optional label | Apply a documented fallback | Original value category and transformation count |
| Reconciliation mismatch | Block publication | Expected total, actual total, and comparison scope |
| Uncertain source completeness | Delay or mark the output provisional | Source cutoff and known gap |
If producing a rejection file, protect it like the primary export. It may contain precisely the unusual records that carry sensitive details. Include validation counts in the result manifest: records examined, accepted, rejected, and transformed. Define whether accepted plus rejected must equal examined, and explain any categories that overlap. Consistent accounting makes partial results easier to assess.
Use previews to explain the rules
A small preview can expose misunderstood columns before someone waits for a large export. Show representative values, units, the selected reporting window, and any planned transformations. Include a summary of important rules, such as requiring one currency per subtotal. Apply the same authorization and masking policies as the final artifact; a preview is still a disclosure of data.
Label a preview as a sample and explain that successful sample validation does not establish the quality of records outside it. When offering a full dry run, account for the source reads it requires and record the snapshot or cutoff used. If the actual export runs later against changed data, it needs its own validation. A preview becomes useful when it clarifies the contract without suggesting that an earlier sample permanently certified the dataset.
Check the hazards introduced by the format
The OWASP guidance on CSV injection explains that untrusted spreadsheet cells can be interpreted as formulas. It also warns that there is no universal CSV sanitization strategy suitable for every spreadsheet application and downstream consumer. Treat this as a destination-specific safety requirement, not a problem solved merely by quoting fields correctly.
For files intended for spreadsheet viewing, define how untrusted text is represented and test the chosen handling in the applications you support, including save-and-reopen behavior. For programmatic imports, preserve the agreed data representation and avoid silently inserting characters that change field values. Where appropriate, consider a workbook format with explicitly typed text cells, and configure the writer so it does not infer formulas or hyperlinks from untrusted strings. Confirm the resulting behavior through actual artifact inspection.
Check other format-specific losses as well. A plain text export should preserve encoding and delimiters. A workbook should retain identifiers as text and present large values without accidental truncation. A PDF should show full labels, units, and pagination without clipping critical columns. The comparison of CSV, JSON, XLSX, and PDF helps align those checks with the intended audience.
Verify the finished artifact before publication
Reopen a generated sample with an independent parser or the target application where feasible. Compare its record count, expected fields, and representative values against the validated input. For large exports, combine full structural checks with targeted content checks and reconciliation totals. Sampling alone cannot prove that every record is correct, so keep per-record validation in the generation path when the contract requires it.
Write the output privately until those checks succeed. Record the artifact size, checksum, schema version, source window, and validation summary. Ensure that an interrupted write cannot appear as a successful file. Test empty datasets, long text, embedded delimiters, international characters, duplicate identifiers, and unusually large values. Include a known failing fixture so the test verifies that publication is actually blocked when a critical rule fails.
Keep validation useful as the data changes
Version validation rules with the export profile and review failures after source changes. A rising rejection rate might reveal a newly introduced category or a broken upstream mapping. Report these shifts without weakening the contract automatically. Use the CSV export best-practices guide as a shared reference for engineers and report owners, and link individual errors to the rule they violate. The goal is a file whose contents, limitations, and transformations are explicit enough for the recipient to use with confidence.
