A source-to-target mapping document (you’ll also see it called an STTM, an S2T, or just “the mapping sheet”) is the deliverable that stands between two systems’ specifications and a working integration: one row per target field, saying where the value comes from, how it’s transformed on the way, and why anyone should believe that. It’s the artifact a consultant hands a client, an analyst hands a developer, and an auditor asks for six months later.
Most teams rebuild it from scratch per project, and most templates you can actually find online are gated behind document-site subscriptions or described in blog posts that never ship the file. This one is the real thing: the same Mapping Specification layout Crossary’s product exports, stripped to a clean, tool-agnostic workbook. Download it, keep it, reuse it on every project — no email, no gate.
What’s in the workbook
- How to use — one page of instructions and the conventions below, so the file explains itself when it’s forwarded.
- Mapping Specification — the heart: 14 columns across Source, Target, Mapping, and Review bands, pre-filled with an 11-row worked example and styled blank rows to extend.
- Source Fields and Target Fields — one inventory sheet per side: field name, object, data type, required flag, description. The inventories are where mapping actually starts.
The Mapping Specification, column by column
Every column earns its place; if your project genuinely doesn’t need one, delete it — but read what it’s for first. The bands matter: a row reads left to right as source → target → rule → why → your decision.
| Column | What it holds |
|---|---|
| # | Row number — one row per target field (an attribute-style target that many sources funnel into gets one row per source). |
| Source Object | The entity on the source side (a table, an object, a segment). Keeps mappings unambiguous when two objects share a field name. |
| Source Field | “—” when no single source field feeds the row — constants, generated values, and honest gaps alike. A gap is signaled by the yellow row and the Unmapped rule, not by this cell. |
| Src Type | The source field’s data type as the source system declares it — not what you wish it were. Type mismatches surface here first. |
| Cardinality | The consulting shorthand: 1..1 required, 0..1 optional, 1..n a repeating attribute-value target. |
| Target Object | The entity on the target side the row lands in. |
| Target Field | The field being populated. Required targets render in red — a load can’t succeed while one is unmapped. |
| Tgt Type | The target’s declared data type. |
| Rule | The transformation in plain English: “Direct copy”, “Constant: …”, “Transform: …”. State the rule as given — never re-derive what a formula “means”; a mis-restated rule is worse than a verbatim one. |
| Evidence (quote) | The exact passage from a spec, field-rules doc, or kickoff note this mapping is based on. The discipline that keeps the whole sheet defensible: no quote, no verified mapping. |
| Assumptions | What must hold for the rule to be correct (“assumes full country names, not ISO codes”). Assumptions written down are testable; assumptions in someone’s head are incidents. |
| Review Decision | The reviewer’s verdict per row — Accept / Edit / Reject / Needs-info (a dropdown in the template). Blue cells mark the band that’s yours to edit. |
| Approved Expression | The reviewer’s corrected or confirmed expression when the drafted rule isn’t quite right. |
| Reviewer Notes | Anything the implementer needs to know that doesn’t fit a column. Notes are decisions — they should survive every copy of the file. |
How to fill it in
The order of operations is the part most templates never tell you, and it’s where hand-built sheets go wrong:
- Inventory first, map second. Fill the Source Fields and Target Fields sheets from each system’s spec before writing a single mapping row. A mapping against a half-known field list produces confident rows that reference fields that don’t exist.
- One row per target field, in target order — the target side is the contract you’re filling. Work down the target inventory and force a decision for every field: mapped, constant, generated, or an explicit gap.
- Quote your evidence as you go. Paste the exact spec sentence that justifies each mapping into the Evidence column while you still know where it came from. Reconstructing evidence at review time is how plausible-but-wrong mappings survive.
- Leave gaps visible. When no source exists, write the row anyway, mark it unmapped, and note the open question. A wrong mapping is worse than an honest gap — the gap gets caught at review; the wrong mapping gets caught in production.
- Review in the blue band only. The reviewer records Accept / Edit / Reject / Needs-info per row and never edits the drafted columns in place — so what was proposed and what was decided stay distinguishable.
The conventions that keep the sheet honest
The template encodes a few rules that sound cosmetic and aren’t:
- Required targets are red. A required field with no mapping is a blocker, not a to-do — the load fails without it. Red text survives every spreadsheet tool, which is why the signal is color, not a hidden flag.
- Honest gaps are yellow rows. An unmapped target stays in the sheet, visibly, until someone decides it. Deleting the row is how gaps become surprises.
- Evidence is verbatim or it isn’t evidence. Paraphrased evidence inherits your assumptions. Quote the spec, name the document, and let the reviewer judge the source.
- Cardinality is derived, not decorative. 1..1 rows are your critical path; 1..n rows (attribute tables, EAV-style targets) are where row counts explode and reviews get skipped.
Where a spreadsheet mapping breaks down
A template fixes the blank-page problem. It doesn’t fix the operational ones, and it’s more honest to name them than to pretend a better layout solves them:
- Rows move underneath reviewers. Someone sorts a range, or cuts and pastes, and a decision recorded on row 41 now sits beside a different mapping. Nothing in a plain spreadsheet detects it.
- Copies fork. The version the client marked up and the version the developer built from stop agreeing, and nobody can say which cell changed.
- Notes die in transit. A reviewer’s comment in one copy never makes it back to the master sheet, and the question it raised gets answered by the deadline instead of a person.
- Nothing validates. A required target with no source, a reference to a renamed field, a type mismatch — the sheet renders them all in the same calm grid.
The same workbook, drafted for you
This template is Crossary’s own export format — that’s not a coincidence, it’s the product. Upload both sides’ specs (Excel, PDF, CSV, JSON, XML, XSD, SQL, or YAML) and Crossary drafts this workbook filled in: every row with the spec quote it’s based on — rendered verbatim, so a weak match shows itself — and an honest abstention wherever nothing fits, for you to review, validate, and export. The product export also adds what a free file can’t: an attestation cover recording who reviewed it and when, and a hidden machine band so a workbook edited in Excel, Google Sheets, or Numbers re-imports without losing a note or overwriting a moved row. How the AI drafting stays trustworthy — evidence quotes, confidence as a triage cue (not a guarantee), abstention — is covered on the AI data mapping page.
Questions, answered straight
Is it actually free?
Yes — the download is a static file with no form in front of it. No email, no account, no watermark. Share it, rebrand it, use it on client work.
Does it work in Google Sheets and Numbers?
Yes. The layout, fills, and red/yellow conventions survive all three major tools. The Review-Decision dropdown is standard data validation — Excel and Google Sheets keep it; treat it as a convenience, not a gate, since spreadsheet tools quietly drop features like sheet protection on save.
Why doesn’t Crossary import my company’s own template instead?
Because the fixed format is what makes the round-trip safe. Crossary exports exactly this workbook and re-imports exactly this workbook, which is why it can match every edited row back losslessly and never lose a reviewer’s note. Arbitrary templates would turn that guarantee into a guess.
What’s different about the workbook the product exports?
Same visible layout — a drift test in our codebase pins the two together. The product export adds an attestation cover (who reviewed, when), an Open Items sheet carrying questions and validation findings, and a hidden machine band that makes re-import lossless. This free file ships clean: no hidden sheets, no tracking.
Is the sample data real?
It’s the committed fixture set from Crossary’s guided sample — a HubSpot contacts export mapped to Salesforce Contact fields, evidence quotes included, plus one deliberate honest gap (Region, which has no HubSpot source and must not be guessed from Country).