The assumption to test
If every cell is copied exactly, an exported table must mean the same thing. That tempting assumption treats column headers as decoration. Instead, read a value as a claim with a subject, a measure and a unit. A bare number preserves only part of that claim.
One number, two quantities
Imagine two parcel records, each containing 12. One column is headed “Mass (kg)”; the other, “Mass (lb)”. Rename both headers “Mass” and match records on that number: unlike quantities now appear equal. Twelve pounds is about 5.44 kilograms, so exact digit preservation did not preserve meaning. Like a dictionary headword, a header frames what follows. That analogy helps explain interpretation; it does not prove that a label is correct.
A check before you compare
Choose one populated cell from each incoming column. Write its meaning as a sentence, such as “Parcel A has a mass of twelve kilograms.” Repeat after export using only the exported material. If the unit, subject or measurement changes or becomes unknowable, the export fails this check. Preserve the original label and any parent headings that supply missing context. Convert units explicitly before comparing quantities, and keep the original value alongside the conversion. Treat this sample as a diagnostic, not proof that every row is correct.
Hypothetical boundary: the label conflicts
Suppose a versioned schema defines a field in kilograms, but its visible header says “Mass (lb)”. A header is evidence, not automatic authority. Decision rule: use the schema’s unit only when a verified import contract makes that schema authoritative for this exact field and version; flag the conflicting label. Otherwise mark the unit unknown and pause numerical comparison until the conflict is resolved. These examples are illustrative, not reported test results. This counterexample defeats a guarantee about copied digits; it does not establish how often exports fail.