The Account-Base Refresh Cycle: Keeping Company Records Current

Keeping company records current is its own job, distinct from keeping contacts current. This guide is for revenue operations, recruiting operations, and anyone answerable for how the account base was gathered and maintained. It gives you a recurring cycle you can stand up and run: build a due queue by tier, refresh firmographics without clobbering verified fields, reconcile corporate events into the hierarchy, and report data-health KPIs against the prior cycle.

Most public advice on CRM freshness is contact-centric - titles, emails, job changes - or a pitch for an enrichment vendor. This one is scoped to company-level decay: acquisitions, rebrands, headcount swings, domain and status changes, and hierarchy drift. Those move slower than contact fields but are harder to catch, and they rarely get their own procedure.

What company-level decay actually is

Company-level decay is the drift of firmographic fields - headcount, funding stage, domain, legal name, status, and corporate parentage - away from reality over time. It behaves differently from contact decay, and treating them as one number will mislead you.

The most-cited aggregate benchmark is that B2B data decays at about 2.1% a month, or 22.5% a year, from MarketingSherpa research that HubSpot uses as its benchmark. Dun & Bradstreet puts overall B2B decay higher, at roughly 30% to 40% per year. Field-level analysis is starker still: email address decay compounds above 70% across a full year. But here is the trap. That 22.5% headline is a blended average. It reflects how differently decay behaves across field types, which is exactly why a single aggregate figure understates the problem for fast-moving sectors like SaaS. Behavioral signals expire in weeks, contact fields follow the monthly rate, and firmographics drift more slowly - so quoting the blend as if it were the firmographic rate is wrong in both directions.

Be honest about the limit here: a company-field-specific decay rate for headcount, domain, and hierarchy is not established publicly as an isolated measured figure. Treat any single number you see as load-bearing but unverified. What you can measure locally is your own freshness age and how often a refresh actually changes a field - that is the rate that matters for your base, and this cycle is built to produce it.

Set the cadence by tier, not by calendar

Refresh cadence should be driven by account tier and field velocity, not a single interval applied to everyone. Companies change size, leadership, and stack frequently, so the base should be refreshed quarterly at minimum, with real-time updates for high-priority accounts.

A workable tiered model runs monthly refreshes for high-velocity fields, event-triggered updates for job changes and bounces, and quarterly audits for firmographic data. That gives most B2B teams the coverage they need without over-spending on enrichment credits. Inside any tier, a record earns a refresh when it crosses a threshold rather than only on the calendar.

The threshold that gates all of this: if bounce rates exceed 2% or records average more than 90 days since last enrichment, begin with a full database refresh before setting your ongoing cadence. Do not try to set steady-state cadence on top of a base that is already stale - you will spend the first several cycles just catching up and never see a clean trend line.

Run the cycle in the right order

The single most consequential decision in this cycle is order of operations: deduplicate and standardize first, then enrich. The recommended sequence is cleanse first, normalize second, enrich third, and skipping or reordering these steps typically multiplies errors downstream.

The reason is both cost and correctness. Deduplicating and standardizing before enrichment stops you paying to append data to duplicate records, and it makes the input for enrichment matching as clean as possible, which improves match rates. Reverse it and the arithmetic turns against you: if you enrich all three copies before you standardize and deduplicate, you now have three enriched records that still represent one company. More data, same problem, three times the credits.

Match rate is where clean inputs pay off. One vendor typically delivers 30-60% match rates on its own; a waterfall that cascades across multiple sources pushes that to 80-95%. Order your providers so a field only escalates to a pricier source when the cheaper one is empty or low-confidence. That escalation logic is the same add-not-replace rule that protects verified fields, applied to cost.

Enriching before you deduplicate does not clean your data. It pays full price to make the mess bigger.

The step-by-step cycle

This is the procedure end to end. Setup is roughly half a day for the queue and one day for the first baseline; each recurring run is hours per segment once the tiers and rules are in place. Roles are noted so you can assign ownership rather than leaving it to whoever notices the drift.

Keep manual effort under about 5% of total records for well-defined cases. If a stage needs a human on more than that, either the rules are wrong or the data is worse than the baseline suggested. Automation is the goal, but the audit trail and frozen-field flags are what make automation safe.

Protect verified fields with frozen flags and an audit trail

A refresh that overwrites a manually corrected value is worse than no refresh, because it launders a bad write behind an improved fill rate. Protecting verified fields relies on three documented mechanisms: frozen-field flags, add-not-replace waterfall logic, and an audit trail.

The frozen flag is the load-bearing piece, and it must be explicit. One hierarchy tool exposes it as a checkbox: when the box is ticked, the policy will not change the current parent, including scenarios where the parent field is meant to remain null. Without such a flag the refresh policy will re-parent or overwrite by default, which is why add-not-replace has to be encoded, not assumed. A field should only update when it is empty or low-confidence.

The audit trail is your record of what changed and where it came from. In Salesforce, Field Audit Trail extends Field History Tracking so you can keep field history indefinitely and maintain a comprehensive record of changes, up to 200 tracked fields per object, compared with 20 for standard field history tracking. By default it archives data after 18 months in production and after one month in sandboxes, and it is part of a paid Shield component priced at roughly 10% of your total Salesforce spend, so scope it to the fields that matter.

Refolk is where I close the ownership gap this section exposes. Frozen flags and audit trails are process, and process needs a named owner. When you need to find the people who have actually built this - RevOps leaders who have run enrichment projects, or data stewards with hierarchy experience - you can ask for them in plain English and get them back.

Detect corporate events and reconcile the hierarchy

Hierarchy drift is the company-level decay that native CRMs are worst at catching. An acquisition changes the corporate structure of both companies: in your CRM, the acquired company's accounts need to be reparented to the acquiring company's ultimate parent, and the Ultimate Parent fields for all affected accounts need to update.

The problem is structural, not lazy. The native Salesforce Parent Account field is a lookup that captures only the direct, one-level-up parent. The Ultimate Parent field is optional and is not maintained automatically, so it goes stale whenever an acquisition or reorganization shifts the chain. Every acquisition mechanically produces a stale field unless an external sync writes the new structure.

To reconcile, key the hierarchy on something stable. Choose a consistent primary key - a DUNS number, website domain, primary address, or product line - and identify the Global Ultimate Parent, the top-level legal entity overseeing all subsidiaries. Then audit for gaps where a missing parent account would break the tree. Run this as a monthly sweep: compare the provider's parent and ultimate-parent keys against the CRM, reparent what has moved, and flag rebrands and domain changes for review. Regular hierarchy audits and automated error-flagging catch these situations before routing and roll-ups run on a structure that no longer exists.

How this cycle goes wrong

The failure modes below are where refresh cycles quietly produce worse data while the dashboard says things improved. Each has a false positive that looks like success, so watch the check, not the headline number.

• Enrich before dedup. Three records for one company all get enriched, inflating counts and burning credits. It looks like a higher record count. Check: run duplicate detection after enrichment and compare to the pre-run count.
• Silent overwrite of verified fields. An automated refresh clobbers a manually corrected headcount. It looks like an improved fill rate. Check: field history shows an integration user as the last editor on a frozen field.
• Stale ultimate parent read as current. Routing and roll-ups run on a corporate structure that no longer exists because nobody reparented promptly. It looks fine until a deal routes to the wrong owner. Check: reconcile parent keys against the provider monthly.
• Composite health score masks a broken field. A single number moves for reasons nobody can trace, so it gets ignored. Check: report per-field dimensions instead of one blended score.
• Single-source enrichment mistaken for coverage. A 30-60% match rate leaves gaps that get read as "no data exists." Check: measure match rate per source; a waterfall raises it to 80-95%.
• Audit trail assumed to be a backup. It records the change but cannot undo a bad write. Check: pair it with a real backup.
• Wrong-company enrichment on a name match. A firmographic API called with a misspelled company name returns no match or a wrong match. Check: standardize and validate the domain before the append.

Report on account data health

Report the health dimensions that drive decisions on the fields that drive decisions, plus exception counts by owner. The standard dimensions are accuracy, completeness, consistency, timeliness, validity, and uniqueness. Do not collapse them into one number - a composite score moves for reasons nobody can trace and gets ignored.

Completeness is populated required fields divided by total required fields across all records; anything below 90% means reps are working with incomplete information. For accuracy, most B2B operations should target 95% or higher, with 90-94% acceptable but flagged for improvement and below 90% treated as critical. Duplicate rate is straightforward - 20 duplicates in 1,000 records is a 2% duplicate rate - and the target is under 2%. Expect the starting point to be rough: typical CRMs carry 10-25% duplicates.

The most useful reporting choice is to report exception counts by owner rather than percentages. A percentage tells leadership the base is 93% complete; an exception count tells an account owner they have 41 records to fix. The second one gets fixed.

Staffing the cycle and keeping it current

The constraint on running this cycle is usually process ownership, not hands to execute. In Refolk's index of professional profiles, US data-quality analysts and data stewards number 2,044 against 1,072 revenue operations managers - the maintenance labor pool is roughly 1.9x the ops-owner pool. The people who can do the work outnumber the people who own the process, so name an owner before you hire executors.

Geography matters if you are building this outside the US. Refolk's index shows US:UK ratios of 5.0x for RevOps managers and 4.1x for data-quality specialists, so a UK or EU team is competing in a far smaller pool and should plan for longer hires. When you do hire, ask for the specific experience this cycle needs rather than a generic title - people who have implemented reparenting automation after an acquisition, or who have run tiered firmographic refresh cadences.

To keep the cycle itself current, re-check three things each quarter. First, the decay assumption: measure how often your refresh actually changes each field and let that observed rate reset your tier thresholds, since the published 22.5% is a blend you should not trust for firmographics. Second, the hierarchy source: confirm your provider's parent keys still reconcile cleanly, because a source that drifts silently is worse than no source. Third, the frozen-field list: as reps correct data by hand, the set of fields that need protection grows, and an add-not-replace policy is only as good as the flags behind it.

Field | Completeness % | Accuracy % | Duplicate % | Freshness age (days) | Match rate %
Headcount | | | | |
Funding stage | | | | |
Domain | | | | |
Status | | | | |
Ultimate parent | | | | |

Targets: accuracy >=95% (critical below 90%), completeness >=90%, duplicates <2%
Exceptions by owner:
Owner name :: count of records failing any target :: oldest freshness age

Run it, trend it, and let the numbers set next quarter's queue. A refresh cycle that produces its own health metrics stops being a periodic cleanup and becomes the thing that keeps the account base honest.