# The Account Record Acceptance Standard: Golden, Remediate, or Reject

*You can grade any new company record Golden, Remediate, or Reject using named fields, valid-range checks, and a 12-month recency line that two operators score the same way.*

- Canonical URL: https://www.refolk.ai/guides/account-record-acceptance-standard
- Pillar: Process, data, and compliance
- Format: Standard
- Published: 2026-10-13
- Last reviewed: 2026-10-13
- Reading time: 17 min

This standard tells you when one company record is done. It is for revenue operations, recruiting operations, and anyone answerable for how account data was gathered, and it hands you a gradeable acceptance gate: grade any newly created, imported, or enriched record as Golden, Remediate, or Reject, using named fields, valid-range checks, a recency line, and source-verification steps that two operators would score identically.

It is deliberately narrow. This is a single-record acceptance gate applied at the moment a record enters the account table, not a database-wide fitness audit, not a one-field conflict verdict, and not a refresh cadence. Most published writing explains the golden-record concept in the abstract. This gives you the field-level checklist that decides whether this record is promoted to the canonical account table and released for routing, segmentation, and reporting.

## What the three grades mean

The three grades are a disposition, not a quality score. Golden means release the record as system-of-record. Remediate means hold it and fix the named gaps first. Reject means the record cannot become an account at all.

A grade is only useful if two people reach the same verdict on the same record. That is the whole point of a standard: it replaces judgement with criteria. Each grade below has entry conditions tight enough that disagreement means someone misread a field, not that the rule was fuzzy.

| Grade | What it means | Entry condition |
| --- | --- | --- |
| Golden | Release as system-of-record | All gates pass: complete, valid, unique, active, fresh, provenance stamped |
| Remediate | Hold and fix named gaps | One or more required fields missing, stale, or failing validity, but entity is real and resolvable |
| Reject | Cannot become an account | Entity dissolved, duplicate of an existing master, or identity unresolvable |

The line between Remediate and Reject is the one operators fumble. Remediate is for a real company with a fixable gap. Reject is for a record that should not exist as an account: a defunct entity, a confirmed duplicate, or a record whose identity cannot be established at all. When in doubt, the test is whether a human could fill the gap with a known-good value. If yes, Remediate. If the entity itself is wrong, Reject.

## The required field set and its format checks

The core required set is six firmographic fields, each with a documented format check: legal name, primary domain, employee count, annual revenue, industry code, and HQ country or region. A record missing any of the six cannot be Golden.

Across CRM configuration guidance the recurring account-level required set is account or legal name, primary domain or website, employee count, annual revenue, industry, and HQ location by country or region. One AI-readiness schema names these as account_name, account_domain as a unique text field, account_industry as a picklist, account_employee_count as a number or range, account_annual_revenue as a number or range, and account_hq_country with region or state. Deduplication practitioners specify the account identity keys more tightly as verified website domain, registered legal name, and country, with the billing entity denoted separately.

The format checks are what make this gradeable rather than a matter of taste.

| Field | Format check | What a valid value looks like |
| --- | --- | --- |
| Legal name | Legal suffix stripped, punctuation normalized | Canonical form, no "Inc"/"Ltd" noise in the match key |
| Primary domain | Resolves with valid MX, lowercased, unique | One registrable domain that returns mail |
| Employee count | Banded picklist, not free number | A defined band, limiting input drift |
| Annual revenue | Banded picklist, min below max | A defined band with no inverted range |
| Industry code | NAICS 2 to 6 digits or SIC 4 digits | A code present in the reference table |
| HQ country | ISO country code; dates ISO 8601 | A valid ISO code, not a free-text country name |

Two of these deserve a note. Industry should map to a standardized code: NAICS is a 2-to-6-digit code where six digits denotes a specific national industry, and SIC is a 4-digit code. Employee and revenue are best enforced as banded picklists rather than free numbers, because open numeric fields drift and resist comparison. Country and dates should use ISO standards, ISO country codes and ISO 8601 YYYY-MM-DD, so that records from different sources line up.

> **Rule:** Six fields, every one validated
>
> A record is eligible for Golden only when all six core fields are populated AND each passes its format check. A populated field that fails validity does not count toward completeness.

## Completeness and validity are two separate gates

Completeness checks that a field is not null. Validity checks that its value is real and in-range. They must run as separate gates, because required-field enforcement predictably produces junk values users type to bypass the save.

This is the quiet failure in most acceptance processes. Make a field mandatory and some fraction of users will type a placeholder to get past it. The record then scores 100% populated while holding a domain that does not resolve, a revenue minimum above its maximum, or an industry string that matches no code. A populated field is not a valid field.

So completeness and validity are the first two gates, in that order. Completeness confirms the six required fields are present, with the published cue being at or above 95% population on routing fields as the pass line. Validity then confirms the domain resolves with valid MX, revenue min is below max, the employee band is a real band, and the industry code exists in the reference table. The validity gate target is zero format or business-rule violations.

#### Completeness feeds validity, never the reverse

1. **Completeness** - Confirm all six required fields are present, cue 95% on routing fields
2. **Validity** - Confirm each value resolves, falls in range, and maps to a reference code
3. **Pass-through** - Only records that clear both proceed to dedup and status checks

*A record must clear completeness and then validity as two distinct gates before it reaches deduplication.*

One ZoomInfo RevOps gate combines the two ideas into a single operational flag: flag any record where more than two required fields are missing or older than 12 months. That is a useful blunt instrument for triage, but for the acceptance verdict, run completeness and validity as named, separate checks so the record's failing reason is specific enough to route.

## The recency line: why 12 months holds

Set the stale line at 12 months on last-verified date for any required field. The line is defensible because B2B data decays at roughly 2.1% per month, which compounds to about 22.5% per year, so by month twelve roughly a fifth of required values are already wrong.

That 2.1% figure traces to a single MarketingSherpa measurement annualized by a decay simulation. Treat it as one finding, not several. The commonly cited job-change rate of 65.8% of contacts per year and the 22.5% annual figure are the same underlying measurement seen from different ends, so do not cite them as independent corroboration. Whole-database decay is cited nearer 30% per year because it also counts merged or closed companies, duplicates, and records that arrived incomplete, and the upper bound reaches about 70.3% per year in high-turnover sectors.

A single last-verified date does double duty here: it is both the provenance timestamp and the recency gate. Within the 12-month outer bound, re-verify by decay tier.

| Field group | Example fields | Re-verify cadence |
| --- | --- | --- |
| High-decay | headcount, job title, funding stage | Monthly |
| Low-decay | primary domain, legal name | Quarterly |
| Stale threshold | any required field | Over 12 months means remediate or reject |

**22.5% - Share of B2B records wrong after one year**

At about 2.1% monthly decay, roughly a fifth of required values are stale by month twelve, which is why the stale line sits at 12 months.

The failure to avoid is accepting accurate-but-stale data as Golden. A wrong-but-populated title or headcount looks trustworthy precisely because the field is filled. Enforce last-verified recency alongside completeness so that an old value fails the gate even though it is present and well-formed.

## Deduplication: confirming the record is unique

A record cannot be Golden until it is confirmed unique or correctly linked to an existing master. Run deterministic matching first, then fuzzy, and never let a shared domain be the uniqueness verdict on its own.

The documented practice is a layered hierarchy. Deterministic account keys are the exact website domain and tax or registration IDs, matched first. Fuzzy signals come second: company-name comparison with legal-suffix stripping and punctuation normalization, plus address proximity. Email-domain matching alone catches about 70% of lead-to-account matches, and fuzzy name adds another 15 to 20%, which means a meaningful share of matches need the fuzzy layer no matter how good the domain data is.

Use published score bands so the review path is itself gradeable.

| Fuzzy score band | Meaning | Action |
| --- | --- | --- |
| 0.95 to 1.00 | Near-certain match | Auto-merge safe |
| 0.80 to 0.95 | Strong match | Human review |
| 0.60 to 0.80 | Possible match | Human validation required |
| Below 0.60 | Likely false positive | Do not merge |

For reference, Salesforce's shipped Company Name matcher uses a threshold of 70. Domain is unreliable alone in both directions: it merges subsidiaries that share a corporate domain and splits one firm that uses several domains. The fix is a second deterministic key, a registration number, LEI, or D-U-N-S, plus explicit parent-child hierarchy edges. Sources disagree on whether a shared domain should default to a parent account; only treat it that way if your explicit account-grain policy says so.

This gate is where thin teams feel the pressure, because getting the match rules and the hierarchy edges right is specialist work. In Refolk's index of professional profiles, only 411 US and 45 UK people hold a dedicated Revenue Operations or RevOps title, a 9.1x gap, which is exactly why a written standard any operator can apply matters more than individual expertise.

I ran this search: `Revenue operations managers at B2B SaaS companies in the San Francisco Bay Area who own CRM data quality.` - [see the full result list](https://www.refolk.ai/s/aexadpmv26).

*Returns named RevOps people in the region where US RevOps title-holders cluster, so you can staff or benchmark the owner of this gate.*

## Operating status and provenance

A Golden record must be confirmed active against an official registry and carry per-field provenance. Status equals active only when the registry returns an explicit current_status value, never when an inactive flag is simply unset.

The status values to resolve are active, inactive or dissolved, acquired, merged, and defunct. The authoritative public confirmation is the official company registry. Open registry data exposes current_status as reported by the registry on the retrieval date, an inactive flag, incorporation_date, and dissolution_date, sourced from national business registries across 140 jurisdictions, typically returning Active, Inactive, or Dissolved. The critical caveat: not all jurisdictions publish status, so you cannot infer active merely because the inactive flag is not set. Acquisition and merger status is not consistently captured by registries and in practice needs a secondary source such as news or press; there is no single authoritative feed for it.

Provenance is the other half of a defensible Golden grade. Governance guidance says to store provenance and consent and to push only trusted fields downstream. Conflict resolution requires a recency rule, a source-trust score, and a per-field tiebreaker, or the golden record is a confident-looking guess. Survivorship practice assigns authority per field, with most-recent-non-null and most-complete rules deciding which source wins. For every accepted value, record four things.

**Per-field provenance stamp**

```
source_system: <where this value came from, e.g. registry, enrichment, manual>
last_verified_date: <ISO 8601 YYYY-MM-DD>
confidence_score: <per-record or per-field confidence from the source>
survivorship_rule: <rule applied, e.g. most-recent-non-null, source-priority>
```

*Attach this to every accepted core field before promotion. One stamp per field, not one per record.*

Without this stamp, conflicting enrichment values resolve by guess, and since 47% of new records arrive with a critical error, a record with no source-trust and recency tiebreakers is a confident guess rather than a system-of-record. Refolk records provenance on the profiles it returns, so the source and recency of each field travel with the data rather than being reconstructed later.

> A populated field is not a valid field, and a valid field is not a verified field.

## The acceptance procedure, step by step

Run the eight steps in order. Each has a clear "done" condition so the final grade follows from the gates rather than from opinion. The procedure is automated where marked and reviewed by a named role elsewhere.

#### Grade one record from intake to release

1. **Normalize on intake** - Strip legal suffixes, lowercase the domain, standardize country to ISO codes, and map industry to a NAICS or SIC picklist. Done means all six core fields sit in canonical format.
2. **Check completeness against the required set** - Confirm name, domain, headcount band, revenue band, industry code, and region are present. Done means required-field population is at or above the pass line, cue 95% on routing fields.
3. **Run validity checks** - Confirm the domain resolves with valid MX, revenue min is below max, the employee band is real, and the industry code exists in the reference table. Done means zero format or business-rule violations.
4. **Deduplicate against the master table** - Match deterministically on domain and registration ID first, then fuzzy on name plus region. Done means the record is unique or linked to an existing master with the parent-child edge preserved.
5. **Verify operating status** - Resolve current_status against an official registry and capture incorporation and dissolution dates. Done means status equals active with an explicit registry value.
6. **Check recency** - Remediate or reject if any required value was last verified over 12 months ago, or a high-decay field is older than its cadence. Done means every required value is inside the recency window.
7. **Stamp provenance** - Write source system, last-verified date, confidence score, and survivorship rule for every accepted value. Done means no core field is missing provenance.
8. **Grade and release** - Assign Golden, Remediate, or Reject. Done means the record is promoted to the canonical table or routed to a named-gap queue with the failing fields listed.

Order can vary at one point. Some teams deduplicate before completeness, on a merge-then-fill logic, while enrichment runbooks sequence standardize, then match and merge, then QA. Pick one order and write it down. The grade must not depend on which operator ran the record.

## How this goes wrong

The acceptance gate fails in predictable ways, and every failure has a check that catches it. Treat this section as the most load-bearing part of the standard, because these are the cases where two operators diverge or where a bad record slips through looking clean.

- **Domain used as the sole dedup key.** Two subsidiaries sharing a corporate domain merge into one account. Check: require a second deterministic key, a registration ID or LEI, or an explicit hierarchy edge, before any merge.
- **Fuzzy name over-matching on common words.** Tokens like "Group", "Holdings", or "Solutions" collide unrelated firms. Check: weight tokens by frequency and raise the match threshold toward 70 or above.
- **Treating an unset inactive flag as active.** A defunct company passes the status check in a jurisdiction that publishes no status. Check: require an explicit current_status value, not the absence of a flag.
- **Completeness without validity.** A record scores 100% populated but holds junk values users typed to bypass a required field. Check: run format and business-rule validation, not just null checks.
- **Accurate-but-stale accepted as Golden.** A wrong-but-populated title or headcount looks trustworthy because the field is filled. Check: enforce last-verified recency alongside completeness.
- **Merge order wrong.** Deleting the wrong record first orphans deal and activity history. Check: sequence parent accounts before child contacts and verify before committing.
- **No per-field provenance.** Conflicting enrichment values resolve by guess. Check: require source, date, and confidence stamp before promotion.
- **Citing the annual decay figure and the job-change rate as independent proof.** They are one finding seen from two ends. Check: treat them as a single source.

> **Watch out:** The most expensive false positive is the dissolved company that passes
>
> A record from a no-status jurisdiction will clear a naive active check because its inactive flag was never set. That record routes to a rep, gets segmented, and shows up in reporting. Always demand an explicit status value.

The matrix below separates the two dimensions that decide a grade: whether the entity is real, and whether the fields are clean. Reading them together is what prevents the common mistake of rejecting a fixable record or promoting an unfixable one.

#### Entity validity against field quality

Horizontal axis runs from Fields incomplete or stale to Fields complete and fresh. Vertical axis runs from Entity unresolvable or dissolved to Entity real and active.

| Quadrant | What it means |
| --- | --- |
| Fixable gap on a dead entity | Reject, the entity itself is wrong |
| Rare edge, re-verify status | Reject or hold, confirm the registry value |
| Named-gap remediation | Remediate, fill the specific fields |
| Clean and confirmed | Golden, promote to canonical table |

*The grade depends on two independent questions, and reading them together prevents mis-grading a fixable record as a reject.*

## The acceptance checklist

Verify every item before calling a record done. If any item fails, the record is Remediate or Reject, never Golden. This is the artifact to adopt as team policy.

#### Account record acceptance checklist

- [ ] All six core fields are populated: legal name, domain, employee band, revenue band, industry code, HQ country or region.
- [ ] Each field passes its format check: domain resolves with valid MX, revenue min below max, industry code in reference table, country as ISO.
- [ ] Required-field population meets the team pass line, with 95% on routing fields as the cue.
- [ ] Deterministic match ran first on domain and registration ID, then fuzzy on name plus region.
- [ ] Record is unique, or linked to an existing master with the parent-child edge preserved and a second deterministic key present.
- [ ] Operating status is an explicit active value from a registry, not an unset inactive flag.
- [ ] Every required field was last verified within 12 months, high-decay fields within their cadence.
- [ ] Each accepted field carries source system, last-verified date, confidence score, and survivorship rule.
- [ ] The grade is recorded, and any Remediate record lists its specific failing fields in the gap queue.

## Keeping the standard current

Adopt this as policy, then keep two things under review: the pass lines and the owner. The thresholds here are documented cues, not universal constants, and the people who can enforce them are scarce enough that the standard has to carry the consistency.

A universal numeric golden pass line above the published cues is not publicly established; teams set it per segment. So treat 95% completeness on routing fields, the 12-month stale line, and the fuzzy score bands as defaults to calibrate against your own routing and reporting needs, and re-check them when a segment's decay profile differs, for example a high-turnover sector nearer the 70.3% annual bound. Review the cues quarterly against how many Golden records later proved wrong.

The owner question is structural. In Refolk's index, US Master Data Management and Data Governance skill-holders outnumber Germany's by 8.2x, 84,138 against 10,244, which means non-US teams more often lack an in-house owner for this work. A fixed, adoptable checklist matters most exactly where bespoke judgement is thinnest. When you need to staff the gate or benchmark who owns it elsewhere, [Refolk](/) lets you ask for the specific people in plain English, such as data governance leads at large companies in a given market, and get them back with the provenance attached. Re-run that search when your team grows or the gate's volume outpaces its current owner.

## Frequently asked questions

### What are the mandatory fields for a golden account record?

Six core firmographic fields recur across CRM configuration guidance: legal or account name, primary domain, employee count, annual revenue, industry, and HQ country or region. Deduplication practice adds verified website domain, registered legal name, and country as the account identity keys, with the billing entity held separately. Treat these six as the required set every record must populate and validate before promotion to the canonical table.

### When is a company record clean enough to release as system-of-record?

A record is Golden only when all six core fields are populated, valid in format, deduplicated against the master, confirmed active in a registry, verified within the last 12 months, and carry per-field provenance. Missing or stale required fields means Remediate; a dissolved entity or an unresolvable identity means Reject. Completeness alone is not enough, because a fully populated record can still hold junk values that fail validity.

### What staleness threshold should I use for account data?

Use a 12-month last-verified line as the reject-or-remediate gate for any required field. It is defensible because B2B data decays about 2.1% per month, so roughly a fifth of values are wrong by month twelve. Re-verify high-decay fields like headcount and funding stage monthly, and low-decay fields like domain and legal name quarterly, within that outer bound.

### Why can't I deduplicate on domain alone?

Domain fails in both directions. Subsidiaries that share a corporate domain merge into one account, while a single firm using several domains splits into many. Email-domain matching catches only about 70% of lead-to-account matches, leaving fuzzy name for another 15 to 20%. Require a second deterministic key such as a registration ID or LEI, plus an explicit parent-child hierarchy edge, before any merge.

### How do I tell completeness from validity?

Completeness checks that a field is not null; validity checks that its value is real and in-range. They must be separate gates because required-field enforcement predictably produces junk values users type to bypass the save. A record can score 100% populated and still hold a domain that does not resolve or a revenue minimum above its maximum. Run format and business-rule validation, not just null checks.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/account-record-acceptance-standard*