What Is Data Mapping in Integrations?

Data mapping is the definition of how information in a source system corresponds to information in a target system. It covers field-to-field links (customer email → debtor email), code translations (tax codes, payment terms, warehouses), and rules for defaults, truncation, and forbidden values.

Without mapping, APIs can “succeed” technically while posting nonsense into finance or CRM. Mapping is where business meaning lives—and where most integration defects hide.

What must be mapped

• Identifiers (SKU, customer code, invoice number)
• Reference data (tax, currency, units, status enums)
• Structural differences (one address blob vs multiple address lines)
• Timing fields (order date vs invoice date vs due date)
• Ownership rules (which system wins when both change)
• Document-type choices (cash sale vs invoice vs credit note)

Why mapping workshops matter

Engineers cannot invent your chart of accounts or product hierarchy. Finance and operations must approve translations. The best integrations treat mapping tables as living configuration with version history—not hard-coded mysteries buried in a single developer’s laptop.

Common mapping pitfalls

• Silent defaults that hide missing data
• One-to-many mismatches (kits, bundles, multi-currency)
• Reusing display names instead of stable codes
• No plan for historical records that used old codes
• Mapping “description” fields as if they were unique keys
• Treating tax as a free-text label instead of a controlled code

Mapping tables as living documents

Store mappings where business users can review them—spreadsheet exports from config, admin UI, or version-controlled files reviewed in pull requests. When SST codes or item categories change, update mapping first, then deploy. A mapping change is a business change; treat it with the same seriousness as a chart-of-accounts edit.

Reference data synchronisation

Sometimes mapping is not enough: you must sync the reference lists themselves (tax codes, warehouses, payment terms). Decide which side authors new codes and how quickly followers update. Ambiguous authorship is how duplicate “Cash” and “CASH” tenders appear.

Testing with fixtures

Keep a suite of anonymised real documents that previously broke mapping. Re-run them when mappings change. This is cheaper than discovering breaks in production on month-end. Include refunds, zero-value lines, and multi-line discounts—the cases demos skip.

A concrete example

Ecommerce sends VAT_SR on a line; accounting expects SST-6. Without an explicit translation, the API may reject the invoice or post to a suspense tax code. A mapping table owned by finance makes the translation reviewable. When tax policy changes, finance updates the table; engineering does not reverse-engineer a new guess.

FAQ

Who approves mapping changes?

Name a finance owner for ledger-bound fields and an operations owner for fulfilment fields. Unowned mapping becomes tribal knowledge and fails during leave or staff turnover.

Is data mapping the same as data migration?

Related but not identical. Migration is often a one-time historical load. Mapping is the ongoing rule set for data synchronization and day-to-day posts. Both need field rules; sync also needs conflict and frequency policies.

Can AI invent our mapping?

Models can suggest likely matches from field names, but finance must approve anything that touches tax, GL, or legal document identity. Treat suggestions as drafts, not authority.

What should we map first in an accounting integration?

Items/SKUs, customers/debtors, tax codes, and document types. Pretty UI fields can wait; wrong tax or item codes cannot.

Where should mapping live—code or configuration?

Prefer configuration for business codes that change. Keep structural transforms in code when they are stable and technical. Reviewable config reduces emergency deploys for a single tax-code rename.

Related concepts

Ongoing consistency: what is data synchronization. Ledger flows: how accounting software integration works. Hub pattern: what is middleware. Foundation: what is API integration.