How to Audit a B2B Database Sample Before Purchase: A Reproducible 10-Step Testing Method

By Rodylyn Villaflores · Co-Founder, LastDatabase

Published: 02 Sep 2026 · Updated: 09 Sep 2026 · Views: 41

A B2B database sample can reveal useful quality signals before purchase.

But opening a spreadsheet, checking a few familiar companies and deciding that the database “looks accurate” is not a reproducible audit.

A stronger evaluation defines the sample, fields, tests, evidence rules and calculations before reviewing the records.

It also distinguishes what can be measured directly from the sample from what would require external verification.

This guide provides a practical 10-step method for auditing a B2B database sample before purchase.

The method covers structure, email syntax, domain and mail-routing signals, duplicates, completeness, company matching, professional attributes, freshness, provenance, suppression metadata and target relevance.

It also explains an important limitation:

A sample result is not automatically the exact quality level of the full database.

The 10-Step B2B Database Sample Audit

Step	Audit area	Primary question
1	Scope and sampling	What exactly are you testing?
2	Structure	Are the promised fields actually present and usable?
3	Email technical checks	Do addresses pass defined syntax, domain and routing checks?
4	Duplicates	How much duplication exists under defined rules?
5	Completeness	Which important fields are populated?
6	Company matching	Do contact and company attributes appear to belong together?
7	Role and professional data	Are titles, departments and seniority internally consistent?
8	Freshness	What evidence shows when the information was observed or checked?
9	Provenance and controls	Can source, verification and suppression metadata be explained?
10	Target relevance	Does the sample actually match the buying specification?

Before Testing: Separate Three Different Questions

A database audit can answer different questions.

Question A: Is this sample internally well formed?

This can often be tested directly from the file.

Examples include:

• missing fields;
• duplicate emails;
• malformed addresses;
• inconsistent country labels;
• unexpected blank values.

Question B: Are the sample's claims correct?

This usually requires evidence beyond the file.

Examples include:

• whether a person currently works at the listed company;
• whether a job title is current;
• whether a company-size value is accurate;
• whether an email mailbox is usable;
• whether a technology signal remains current.

Question C: What does the sample imply about the entire database?

This is a statistical question.

The answer depends on how the sample was selected, its size, the population structure and the uncertainty of the resulting estimate.

A convenient vendor-selected sample is not automatically a probability sample of the entire database.

Step 1: Define the Audit Scope Before Looking at Results

Write down what the database is supposed to contain.

For example:

• country: United States;
• industry: software;
• seniority: director and above;
• contact type: B2B;
• required fields: name, company, title and email;
• optional fields: phone, LinkedIn URL, revenue and employee size.

This becomes the audit specification.

Without a specification, it is easy to change the definition of “good data” after seeing the sample.

Record the Sample Selection Method

Ask how the sample was selected.

Possible methods include:

• random selection;
• systematic selection;
• stratified selection;
• first available records;
• vendor-selected examples;
• records from a particular segment;
• customer-selected filters.

These are not statistically equivalent.

A hand-picked sample may still be useful for inspecting format and fields, but it should not automatically be treated as representative of the entire database.

Do Not Choose Sample Size by a Universal Rule

There is no defensible rule that “100 records is always enough” or “500 records proves database accuracy.”

The appropriate sample design depends on the intended inference, population, expected variation and desired precision.

The U.S. Census Bureau notes that sample estimates contain sampling uncertainty and that larger samples generally reduce sampling error, all else equal.

If you are making population-level claims from a sample, statistical uncertainty should be reported rather than hidden.

Step 2: Audit File Structure and Field Definitions

Start with the simplest question:

Did you receive the fields you were promised?

Create a field inventory.

Field	Promised?	Present?	Definition clear?	Test needed
Email	Yes/No	Yes/No	Yes/No	Syntax/domain/routing
Company	Yes/No	Yes/No	Yes/No	Company matching
Job title	Yes/No	Yes/No	Yes/No	Role validation
Industry	Yes/No	Yes/No	Yes/No	Classification review
Country	Yes/No	Yes/No	Yes/No	Target relevance
Employee size	Yes/No	Yes/No	Yes/No	Definition/source review
Source/freshness	Yes/No	Yes/No	Yes/No	Provenance review

Check Whether Field Names Hide Ambiguity

A column named date tells you very little.

It could mean:

• date imported;
• date collected;
• date verified;
• date enriched;
• date updated;
• date exported.

Similarly, verified is incomplete unless the provider explains what was verified.

Our technical definition of verified B2B data explains why verification claims should identify the check performed.

Step 3: Test Email Technical Quality in Layers

Do not reduce email quality to one “valid” column.

Separate the checks.

Layer 1: Syntax

Check whether the address is structurally plausible.

Examples of obvious failures can include:

• missing @ separator;
• missing domain;
• invalid structural formatting;
• unexpected whitespace or parsing errors.

Syntax alone does not prove a mailbox exists.

Layer 2: Domain

Determine whether the domain can be resolved under the methodology being used.

This is stronger than syntax but still does not prove the recipient mailbox is usable.

Layer 3: Mail routing

Review relevant SMTP mail-routing evidence.

Do not use the simplistic rule:

“No explicit MX record = invalid email domain.”

SMTP rules include an implicit MX fallback in certain circumstances, while a Null MX explicitly signals that a domain does not accept email.

Our B2B email verification guide explains these technical distinctions in detail.

Layer 4: Mailbox-related signals

If mailbox-level testing is performed, document:

• the method;
• the test date;
• accepted, rejected or uncertain status;
• catch-all behavior;
• temporary failures;
• limitations of the method.

A mailbox-related signal is still not a guarantee of future delivery or inbox placement.

See our deliverability versus verification guide.

Email Verification and Sender Authentication Are Separate

SPF, DKIM and DMARC concern sender authentication.

They do not verify that a purchased recipient address belongs to the intended person.

Google's current Gmail sender requirements also include authentication, DNS, TLS, message-format and spam-rate requirements.

Those sender-side requirements should not be presented as recipient-database verification.

Step 4: Measure Duplicates Under More Than One Definition

Start with exact duplicate measurements.

Then define normalized and entity-level duplicates separately.

Useful tests can include:

• exact duplicate rows;
• exact normalized email duplicates;
• duplicate phone numbers;
• duplicate person-company combinations;
• candidate person duplicates;
• candidate company duplicates.

Do not combine these into one unexplained “duplicate rate.”

Our B2B data deduplication guide explains exact matching, fuzzy matching, precision, recall and false merges.

Duplicate Rate Formula

For an explicitly defined duplicate rule, a basic descriptive calculation is:

Duplicate Rate = Duplicate Records ÷ Records Tested × 100

The result is meaningful only when “duplicate record” is clearly defined.

An exact-email duplicate rate is not the same metric as a person-level duplicate rate.

Step 5: Measure Field Completeness

Completeness asks whether expected fields contain usable values.

A basic field-level calculation is:

Field Completeness = Records With Usable Field Value ÷ Eligible Records × 100

The denominator matters.

If a field is only applicable to a subset of records, using the entire sample as the denominator can distort the result.

Build a Completeness Matrix

Field	Eligible records	Populated	Blank/invalid	Completeness
First name	___	___	___	___%
Last name	___	___	___	___%
Email	___	___	___	___%
Company	___	___	___	___%
Job title	___	___	___	___%
Industry	___	___	___	___%

Completeness Is Not Accuracy

A field can be 100% populated and still contain incorrect information.

This distinction is central to our 12-metric B2B data quality framework.

Never convert a completeness percentage into an accuracy percentage.

Step 6: Test Person-to-Company Matching

For a reviewed subset, ask whether the professional contact appears to be associated with the listed company.

Possible classifications are:

• Pass — evidence supports the relationship;
• Fail — evidence contradicts the relationship;
• Uncertain — available evidence is insufficient.

Do not force uncertain records into pass or fail merely to produce a cleaner percentage.

Company Matching Requires Defined Evidence

Potential evidence might include appropriate authoritative company information, professional information or another source suitable for the audit methodology.

The audit should record:

• what source was reviewed;
• when it was reviewed;
• what attribute was compared;
• the resulting status.

This creates a reproducible evidence trail.

Do Not Confuse Domain Matching With Employment Proof

An email domain matching a company domain can be a useful signal.

It does not automatically establish that every other professional field is current.

A person may have changed roles, moved departments or left the company while an older record remains in a database.

Step 7: Audit Job Title, Department and Seniority

Professional attributes should be tested separately.

For example, a contact can be correctly associated with a company while the listed title is outdated.

Review:

• job title;
• department;
• seniority;
• company;
• location;
• industry classification.

Separate Observed Fields From Derived Fields

A department can be derived from a job title.

Seniority can also be classified from title text.

Those derived values should not automatically be treated as independently observed facts.

Our B2B data enrichment guide explains observed, normalized, classified, inferred and estimated attributes.

Use Pass, Fail and Uncertain

A three-state model is useful throughout a manual audit.

Status	Meaning
Pass	The defined evidence supports the tested claim
Fail	The defined evidence contradicts the tested claim
Uncertain	The available evidence cannot establish either result confidently
Not applicable	The test does not apply to this record

This prevents missing evidence from being silently counted as either success or failure.

Step 8: Audit Freshness Evidence

Ask what the provider means by “updated.”

Important timestamps can include:

• source observation date;
• verification date;
• enrichment date;
• database import date;
• record modification date;
• export date.

These dates are not interchangeable.

A database row updated yesterday can still contain a job title observed much earlier.

Our B2B data freshness framework explains this distinction.

Measure Age Only When the Timestamp Has Meaning

If a genuine observation or verification date exists, you can calculate its age at the audit date.

For example:

Evidence Age = Audit Date − Relevant Observation or Verification Date

Do not calculate “data freshness” from a technical database timestamp unless that timestamp is documented as representing the underlying check.

Step 9: Audit Provenance, Verification and Suppression Metadata

Ask whether important claims can be traced to meaningful metadata.

Useful questions include:

• Is a source category available?
• Is an observation date available?
• Can observed and inferred fields be distinguished?
• Is the verification method defined?
• Can a correction be propagated?
• Is suppression status represented?
• Can records be screened against suppression before outreach?

Our B2B data sources guide explains provenance in more detail.

Suppression Is Not the Same as Verification

A technically usable email address can still be suppressed from marketing.

Conversely, an unsuppressed record is not automatically technically valid.

These are separate controls.

See our opt-out and suppression workflow.

Step 10: Measure Target Relevance

A technically clean database can still be commercially poor if it does not match the requested audience.

Compare each eligible sample record against the original buying specification.

Potential criteria include:

• country;
• industry;
• job function;
• seniority;
• company size;
• revenue band;
• technology;
• business type;
• geographic region.

Target-Relevance Formula

For a defined target specification:

Target Relevance = Records Meeting All Required Target Criteria ÷ Eligible Records Tested × 100

Again, this is a descriptive result for the audited records unless the sample design supports broader inference.

Build a Row-Level Audit Worksheet

A practical worksheet might contain these columns:

Column	Purpose
sample_id	Stable audit identifier
email_syntax	Pass/Fail
domain_status	Pass/Fail/Uncertain
mail_routing	Pass/Fail/Uncertain
duplicate_status	Unique/Duplicate/Candidate
company_match	Pass/Fail/Uncertain
title_match	Pass/Fail/Uncertain
freshness_evidence	Date/Unknown
source_evidence	Defined source category/Unknown
suppression_status	Applicable status/Unknown
target_match	Pass/Fail
review_notes	Evidence and exceptions

Keep Raw Evidence Separate From Conclusions

Do not overwrite the original sample while auditing it.

Keep:

1. the original sample;
2. a normalized working copy;
3. the audit results;
4. external evidence notes;
5. the final summary.

This makes the process easier to reproduce and review.

Example Audit: 200 Records

Consider a hypothetical audit of 200 records.

Suppose the reviewer finds:

• 196 syntactically plausible emails;
• 190 records with usable company names;
• 184 populated job titles;
• 6 exact normalized-email duplicate rows;
• 170 records meeting the defined target specification;
• 20 records with insufficient evidence for a current-title decision.

These figures are deliberately hypothetical.

They are not LastDatabase performance results.

Calculate Each Metric Independently

Using the hypothetical example:

Email Syntax Pass Rate = 196 ÷ 200 × 100 = 98%

Company Completeness = 190 ÷ 200 × 100 = 95%

Job-Title Completeness = 184 ÷ 200 × 100 = 92%

If six records are duplicates under the explicitly defined exact-email rule:

Descriptive Exact-Email Duplicate Rate = 6 ÷ 200 × 100 = 3%

If 170 records meet all required targeting criteria:

Descriptive Target Relevance = 170 ÷ 200 × 100 = 85%

These metrics measure different properties.

Do not average them into a meaningless single “94.6% database quality” score.

Why a Single Quality Score Can Mislead

A single score requires decisions about weighting.

Should email syntax count as much as current employment?

Should completeness count as much as target relevance?

Should an uncertain title be scored as incorrect?

There is no universal weighting that answers these questions for every buyer.

A scorecard of separate metrics is usually more transparent.

Do Not Treat Uncertain as Automatically Wrong

If 20 records lack enough evidence to confirm a current title, that does not prove all 20 titles are incorrect.

Likewise, counting them all as correct would be unjustified.

Report uncertainty separately.

Do Not Extrapolate a Convenience Sample Without Warning

This is one of the most important rules in the audit.

Suppose 98 of 100 vendor-selected sample records pass a particular test.

That observation does not by itself prove that exactly 98% of a multi-million-record database would pass the same test.

The sample may differ from the overall population.

It might contain:

• easier-to-verify records;
• particular countries;
• larger companies;
• more recent records;
• selected industries;
• hand-picked examples.

Selection methodology matters.

Probability Samples Support Stronger Inference

When a sample is selected using a statistically appropriate probability design, population estimates can be accompanied by measures of sampling uncertainty.

The U.S. Census Bureau's statistical standards require sample design and estimation methods to reflect the intended level of precision and require appropriate uncertainty measures for conclusions based on sample data.

A B2B buyer does not need to reproduce a federal statistical program.

The practical lesson is narrower:

If you want to generalize from a sample to millions of records, document how the sample was selected and quantify uncertainty appropriately.

Sampling Error Is Not the Only Error

A mathematically well-designed sample can still produce a poor audit if the tests themselves are wrong.

The Census Bureau distinguishes sampling error from nonsampling error.

For a B2B database audit, analogous nonsampling problems can include:

• incorrect verification rules;
• manual-review mistakes;
• bad field definitions;
• incorrect company matching;
• coding mistakes;
• missing evidence;
• classification errors.

Increasing sample size does not automatically repair a flawed audit methodology.

Segment-Level Results Can Reveal Hidden Problems

An overall result can hide variation.

Where sample design and sample size permit, inspect results by meaningful segment.

Examples include:

• country;
• industry;
• company size;
• job seniority;
• source category;
• record age;
• email domain type.

A database might perform differently across segments.

Use the Same Rules for Every Record

A reproducible audit should define the decision rules before reviewing the outcome.

For example:

Company Match = Pass only when the defined evidence supports the contact-company relationship.

Company Match = Fail when credible evidence contradicts it.

Company Match = Uncertain when neither conclusion is sufficiently supported.

Changing the rule from record to record introduces reviewer bias.

Record the Audit Date

Database quality changes.

A review performed today describes evidence available today.

Titles, companies, domains and mailboxes can change later.

Every audit report should therefore include:

• audit date;
• sample source;
• sample size;
• selection method;
• tests performed;
• external evidence sources;
• limitations.

What a Good Audit Report Should Contain

A useful final report can use this structure:

1. database and package tested;
2. audit objective;
3. sample-selection method;
4. sample size;
5. field definitions;
6. test methodology;
7. results by metric;
8. uncertain results;
9. segment findings;
10. limitations;
11. audit date;
12. review notes.

Sample Audit Scorecard

Metric	Result	Status	Notes
Email syntax	___%	Pass/Review	Defined syntax methodology
Domain/routing	___%	Pass/Review	Include uncertain results
Exact duplicates	___%	Pass/Review	Define duplicate key
Company completeness	___%	Pass/Review	Completeness only
Company match	___%	Pass/Review	External evidence required
Title match	___%	Pass/Review	Report uncertain separately
Freshness evidence	___%	Pass/Review	Define timestamp meaning
Provenance coverage	___%	Pass/Review	Define required metadata
Target relevance	___%	Pass/Review	Use original buying specification

Do Not Invent Pass Thresholds

This guide deliberately does not declare universal rules such as:

• “95% means good”;
• “90% means verified”;
• “less than 2% duplicates is acceptable.”

The acceptable threshold depends on the use case, contractual promise, risk, price and buyer requirements.

Define thresholds before the test when possible.

Compare the Sample With the Vendor's Specific Claims

If a provider promises a defined characteristic, test that characteristic directly.

For example, if a package is described as containing:

• United States contacts;
• technology companies;
• director-level professionals;
• business emails;

the audit should measure those four claims separately.

A high email-syntax rate cannot compensate for poor country targeting.

Ask for Definitions, Not Just Percentages

If a provider states that data is “verified,” ask:

• What was checked?
• When was it checked?
• What counts as pass?
• How are uncertain results handled?
• Does the claim apply to every field or only email?

If a provider states an “accuracy rate,” ask for the numerator, denominator, sample-selection method and test definition.

This extends the buyer questions in our 15-point B2B database due-diligence checklist.

Sample Audits Should Be Reproducible

Another competent reviewer should be able to understand how you reached the result.

That means preserving:

• input sample;
• normalization rules;
• test definitions;
• scripts or formulas where relevant;
• review evidence;
• classification rules;
• result calculations.

The Census Bureau's statistical quality standards similarly emphasize documentation sufficient to replicate and evaluate estimation operations.

How LastDatabase Approaches Sample-Based Quality Claims

LastDatabase's editorial methodology does not treat a small sample as automatic proof of the quality of an entire database.

When sample-based evidence is discussed, the sample, methodology, tested metric and limitations should be stated.

We also distinguish descriptive sample results from broader population claims.

Related transparency resources include:

• Methodology
• Data Quality
• Data Sources
• Compliance
• Privacy Center
• Opt-Out
• Editorial Policy

Frequently Asked Questions

1. How do I audit a B2B database sample before buying?

Define the buying specification, record the sample-selection method, and test structure, email signals, duplicates, completeness, company matching, professional attributes, freshness, provenance, suppression metadata and target relevance.

2. How many B2B contacts should I test?

There is no universal sample size that proves database quality. The appropriate size depends on the intended inference, population variation, sample design and required precision.

3. Does testing 100 contacts prove the quality of the full database?

No. A 100-record sample can provide useful observations, but generalizing its results requires consideration of selection method and statistical uncertainty.

4. What should I check first in a database sample?

Start with the buying specification and field definitions. Confirm that the sample contains the promised fields before evaluating more complex quality claims.

5. Is email syntax enough to verify an email?

No. Syntax only evaluates structural plausibility. Domain, mail-routing and mailbox-related checks provide different evidence and have their own limitations.

6. How should duplicate rate be calculated?

Define the duplicate unit first. Exact-email duplicates, duplicate rows, person duplicates and company duplicates are different metrics and should be reported separately.

7. Is field completeness the same as accuracy?

No. A field can be populated while containing an incorrect, stale or mismatched value.

8. How can I test job-title accuracy?

Define acceptable external evidence, compare the listed title against that evidence, record the audit date, and classify the result as pass, fail or uncertain.

9. What does an uncertain result mean?

It means the available evidence does not justify either a confident pass or a confident failure. Uncertainty should be reported rather than hidden.

10. Can a vendor-selected sample represent the whole database?

Not automatically. Vendor selection can introduce selection effects, so population-level claims require an appropriate sampling design and uncertainty analysis.

11. Should I create one overall database-quality percentage?

Usually, separate metrics are more informative. Combining syntax, completeness, matching, freshness and relevance into one number requires subjective weighting.

12. What should a database sample audit report include?

Include the audit objective, sample source, selection method, sample size, test definitions, results, uncertain cases, limitations, evidence sources and audit date.

Primary References

• U.S. Census Bureau — Statistical Quality Standard A3: Developing and Implementing a Sample Design
• U.S. Census Bureau — Statistical Quality Standard D1: Producing Direct Estimates from Samples
• U.S. Census Bureau — Statistical Quality Standard E1: Analyzing Data
• U.S. Census Bureau — Statistical Quality Standard E2: Reporting Results
• U.S. Census Bureau — Sample Size and Sampling Error
• Google — Email Sender Guidelines
• RFC 5321 — Simple Mail Transfer Protocol
• RFC 7505 — Null MX

Conclusion

A B2B database sample is most useful when it is treated as an audit dataset rather than a sales preview.

Define what you intend to test before looking at the results.

Measure technical email signals, duplicates, completeness, company relationships, professional attributes, freshness evidence, provenance and target relevance separately.

Preserve uncertain results rather than forcing every record into pass or fail.

Most importantly, distinguish what you observed in the sample from what you can legitimately conclude about the entire database.

A reproducible audit should answer four questions:

What was tested? How was it tested? What did the sample show? What are the limits of that conclusion?

Those questions provide far more information than a single unexplained “accuracy percentage.”

About the Author

Rodylyn Villaflores

Co-Founder, LastDatabase

Rodylyn Villaflores is Co-Founder of LastDatabase. She contributes to LastDatabase educational content covering B2B data, lead generation, sales prospecting, data quality, and responsible data use.

View author profile →