A recipient file can look complete and still be unsafe to launch: one duplicate email can create two gifts, one stale address can turn a thoughtful moment into a support ticket, and one suppression conflict can convert an operational shortcut into a governance failure. This guide pairs a practical, versioned audit workbook with a decision system for deciding what blocks a corporate gifting campaign, what may proceed with an owner, and what evidence should survive sign-off.
Download the 2026.09 audit kit
Download the localized XLSX workbook and UTF-8 CSV input template. Version 2026.09; asset key recipient-data-quality-audit-2026. Both files contain synthetic examples only.
The workbook contains ten operational sheets: Instructions, Field Dictionary, Import, Validation Results, Duplicate Review, Address Review, Consent & Retention, Exception Queue, Summary Scorecard, and Change Log. The CSV is deliberately formula-free so a source-system owner can export or map data without inheriting spreadsheet logic. Keep the workbook as the controlled review copy and the CSV as the replaceable intake layer.
| Artifact | Best use | Acceptance evidence |
|---|---|---|
| XLSX workbook | Formula-driven triage, owner assignment, scorecard | Zero formula errors, all blockers closed, warnings owned |
| CSV template | Source mapping and reproducible re-export | UTF-8 encoding, stable headers, synthetic test row removed |
Why recipient data quality is a launch decision
Data quality is not a single percentage. A file may be 99.8% populated and still contain the one suppressed executive who must not receive a shipment. Treat completeness, validity, consistency, uniqueness, timeliness, consent, and ownership as separate dimensions. A high average never cancels a critical defect.
For postal fields, Universal Postal Union guidance explains that addressing practices vary by country and that country-specific templates matter; its current page also describes S42 address components and templates. USPS Publication 28 is useful for United States formatting, but it should not be applied as a global rule. Unicode CLDR supports locale-aware software data, yet it does not prove that a person chose the correct language. The audit therefore tests plausibility and routing readiness, not identity.
Use one severity model across teams
Use three outcomes. Block means the campaign cannot proceed for the affected row or launch population: examples include a missing delivery channel, suppression conflict, impossible country routing, or duplicate that could cause double fulfillment. Warn means a named owner may accept a bounded risk, such as an older verification date with a recent authoritative source refresh. Pass means the documented rule produced no exception; it is not a guarantee of delivery.
| Outcome | Who decides | Required evidence | Release behavior |
|---|---|---|---|
| Block | Source owner plus program lead | Corrected source record and clean rerun | Hold row or campaign |
| Warn | Program lead with data owner | Reason, expiry date, accountable owner | Proceed only within scope |
| Pass | Automated check, sampled by reviewer | Rule version and audit fingerprint | Eligible for sign-off |
Do not quietly convert a block into a warning to meet a date. If a business sponsor accepts risk, record the exact exception, affected population, compensating control, expiry, and approver.
Why a score cannot override a blocker
A weighted average measures overall condition, while a blocker represents a categorical safety or execution constraint. Keep both signals, but apply the stricter decision.
Field-by-field audit decisions
1. Recipient identifier
Require a stable pseudonymous key that survives exports without exposing an employee number. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is a one-to-one reconciliation between source and audit row; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
2. First and last name
Allow local name order and single-name cultures; do not reject a record only because it lacks a Western two-part pattern. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is a locale-aware display-name sample approved by the regional owner; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
3. Email syntax
Check one at-sign, a plausible domain, surrounding whitespace, and control characters; syntax cannot prove mailbox ownership. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is a clean syntax scan and a separate delivery-channel decision; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
4. Phone number
Normalize country context before comparing digits and never invent a country code from language alone. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is the original value, normalized value, and transformation rule; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
5. Country code
Require an explicit two-letter routing value sourced from the program record, not inferred from postal text. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is a permitted-country lookup and source-field mapping; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
6. Address line
Preserve local script, unit information, and line order; a nonempty string is not enough. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is country-specific sampling against postal guidance; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
7. City or locality
Validate requiredness by destination rather than forcing one global city rule. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is a destination-specific rule and sample result; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
8. Region
Make state or province conditional on the destination and carrier rule. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is the rule branch and owner for ambiguous regions; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
9. Postal code
Validate structure by country; never apply a United States pattern worldwide. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is country rule version and failing examples; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
10. Locale
Use locale for presentation, not as evidence of residence, consent, or citizenship. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is recorded preference source and fallback language; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
11. Consent state
Require an explicit source and timestamp where consent is the operating basis. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is source event, timestamp, and policy mapping; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
12. Suppression state
A suppression match overrides campaign eligibility even when every other field passes. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is suppression-list version and match key; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
13. Last verified date
Define freshness by source volatility and event timing instead of one arbitrary universal age. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is freshness threshold, source refresh, and exception expiry; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
14. Source system
Every imported value needs a named system of record and extraction time. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is export job identifier and accountable system owner; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
15. Data owner
Do not allow an exception queue with nobody empowered to correct the source. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is named role, due date, and escalation route; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
16. Duplicate key
Use multiple candidate keys and route fuzzy matches to review rather than automatic deletion. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is cluster membership, survivor rule, and reviewer decision; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
17. Campaign eligibility
Separate employment or customer eligibility from address quality so one rule cannot conceal another. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is eligibility snapshot and policy version; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
18. Gift restriction
Record country, value, category, and recipient restrictions independently of contact fields. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is approved policy decision and affected rows; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
19. Delivery channel
Require a viable channel for the chosen fulfillment path and a defined fallback. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is channel test and fallback owner; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
20. Timezone
Use timezone only for scheduling; do not infer it from language when location is missing. Treat the result as Warn when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is explicit zone or documented scheduling default; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
21. Character encoding
Detect replacement glyphs, lossy transliteration, and byte-order mistakes before upload. Treat the result as Block when the defect can misroute a gift, contact a suppressed recipient, create duplicate fulfillment, or prevent accountable correction. The data owner should repair the authoritative source rather than editing only the delivery file. Acceptance evidence is round-trip UTF-8 test and visual sample; retain the rule version, affected row count, before-and-after extract fingerprints, and reviewer decision so a later operator can reproduce the outcome.
Run the audit from source to sign-off
Start with a copy of the localized workbook. The source owner maps fields in Field Dictionary and exports a fresh CSV; the program operator records campaign scope, extraction time, and expected row count. Paste values into Import, never formulas. Recalculate, then compare imported count with the source control total. If they differ, stop before interpreting any score.
Work in this order: first suppression and eligibility, then duplicate candidates, then address routing, then locale and presentation, then timeliness and ownership. Assign every blocker to the system that can actually correct it. After correction, discard the patched working row, re-export from the source, and rerun the entire file. Finally, freeze the audit fingerprint, workbook version, counts, unresolved warnings, approvers, and working-copy deletion date.
-
Expected and imported row counts reconcile.
-
Formula and reference scan has no spreadsheet errors.
-
Every blocker is closed or the affected row is removed under policy.
-
Every warning has an owner, rationale, and expiry.
-
Duplicate clusters have a documented survivor rule.
-
Country samples preserve local script and postal order.
-
Suppression and consent evidence uses the current source snapshot.
-
Working copies have a deletion owner and date.
Hypothetical case A: a 10,000-row employee file
This hypothetical case is not a Giftpack customer result. A company prepares 10,000 employee anniversaries from an HR system. The control total is 10,000, but the import contains 10,047 rows. Duplicate review finds 31 exact email pairs and 16 near matches caused by contractors later converted to employees. Another 22 rows lack a country code, and 14 appear on the current suppression file.
The program lead blocks the launch rather than subtracting exceptions from an average score. Human Resources resolves employee-versus-contractor survivor records in the source. Regional operations supplies country codes only where it has authoritative employment-location evidence. Privacy operations confirms the suppression snapshot. The team re-exports 9,986 eligible rows; the difference is reconciled to 14 suppressed recipients. Acceptance requires zero unresolved duplicate clusters, zero missing routing country, a preserved suppression snapshot identifier, and a signed count bridge from 10,000 source people to 9,986 eligible recipients.
Hypothetical case B: a mixed-script CRM export
This second hypothetical case starts with a CRM export containing Japanese, Korean, Traditional Chinese, and Latin-script addresses. A normalization job transliterates several local-script address lines, strips apartment markers, and maps language to country. The workbook flags replacement characters, blank unit fields, and conflicting country-versus-postal patterns.
The team rejects the transformed file. Sales operations keeps original-script fields, stores normalized search fields separately, and removes country inference from language. Regional reviewers sample every country rule and confirm line order against destination guidance. The recovery run preserves both original and normalized values, but fulfillment consumes the locally formatted version. Acceptance evidence includes a UTF-8 round trip, twenty sampled addresses per active country, a documented fallback for unsupported formats, and no rule that treats locale as residence proof.
Recover without hiding the failure
A failed audit is useful when it identifies the failing layer. If formulas return an error, stop and restore the approved workbook version before touching source data. If counts drift, compare the export query, filters, and extraction timestamp. If a duplicate is false, refine the candidate rule and re-review the whole affected cluster. If local characters render incorrectly, repair the font or encoding path and repeat visual checks; do not transliterate simply to make the spreadsheet look clean.
Keep recovery evidence separate from public recipient data. Record the error fingerprint, first failing step, strategies attempted, real transfer or rerun counters, source checksum, repaired version, and next owner. A rerun passes only when the original defect is absent and no new blocker appears. Never carry forward a manually patched delivery file as if the source were fixed.
Minimize data and control the working copy
Recipient audit files contain operationally sensitive information. Federal Trade Commission guidance recommends collecting only what is needed, restricting access, protecting retained information, disposing of data securely, and planning for incidents. For processing subject to the General Data Protection Regulation, Article 5, teams should assess principles including data minimization, accuracy, storage limitation, and accountability with qualified counsel. This workbook is an operational aid, not a legal determination.
Use synthetic data while configuring rules. Limit live extracts to the minimum fields necessary for the chosen delivery path. Separate suppression evidence from broad campaign access. Encrypt transfers, restrict membership, log exports, and set deletion dates for working copies. If someone needs a long-lived audit record, preserve counts, fingerprints, decisions, and rule versions rather than every recipient value.
Acceptance scorecard and sign-off evidence
The Summary Scorecard is a launch gate, not a vanity metric. Require imported-count reconciliation, zero spreadsheet errors, zero unresolved blockers, warning ownership, country sampling, duplicate survivor decisions, suppression evidence, and a deletion schedule. The readiness score may help compare reruns, but it cannot overrule a blocker.
| Control | Pass condition | Evidence |
|---|---|---|
| Population | Source, imported, excluded, and eligible counts bridge exactly | Count reconciliation |
| Critical defects | No unresolved block outcome | Clean validation and exception queue |
| Warnings | Each has owner, reason, scope, and expiry | Signed exception record |
| Localization | Country samples preserve script and ordering | Regional review sample |
| Governance | Working-copy deletion and incident owner are recorded | Retention and response record |
Source basis and version limits
Last verified 2026-09-24. The Universal Postal Union addressing page supports country-specific address practices and standards; the Unicode CLDR project supports locale data used by software; USPS Publication 28 provides United States postal addressing standards; the FTC business guide covers protective and disposal practices; and GDPR Article 5 states data-processing principles in the European Union.
Version 2026.09 uses transparent operational thresholds and synthetic test rows. It does not call a mailbox, validate a natural person, replace carrier or postal tools, decide lawful basis, or establish compliance. Refresh official links quarterly, review scoring annually, and issue a new version immediately after a formula, encoding, or locale defect.
Turn a clean file into a controlled launch
A reliable recipient audit changes the launch conversation from “the file looks mostly complete” to “every critical decision has an owner and reproducible evidence.” Keep blocks absolute, warnings scoped, corrections in the source, and working copies short-lived. Use the workbook before every material launch and whenever the population, routing countries, source query, suppression list, or transformation logic changes.
Once the file is accepted, Giftpack can serve as the execution layer for the approved gifting program, including reward, merchandise, automation, and global fulfillment workflows. The platform does not replace source-system ownership, privacy review, legal advice, postal validation, or the employer’s eligibility decisions; it should receive only the controlled, approved data needed to execute the program.