What an Address File Audit Finds Before the Next Mailing

A mailing file can look tidy and still be expensive. The street column is filled in. The ZIP column is mostly filled in. Nothing appears twice when you sort by name. Then the file reaches a printer, a board review, or a new campaign, and nobody can answer the basic question: which rows are trustworthy enough to use?

That is the job of an address file audit. It should not end with a new CSV and a vague promise that the list is cleaner. It should show what happened to the file, where the uncertainty sits, and which assumptions turned that uncertainty into a cost estimate.

RevAddress publishes a complete sample Address Quality Report for exactly that reason. The sample runs a committed 20-row fixture through the same aggregation and report-rendering path as a paid audit. The neighborhood figures come from current federal data for the fixture’s real census tracts. The deliberately bad rows remain visible, so the report is proof of the method rather than a perfect score assembled for a sales page.

Here are the eight questions that report answers.

1. How much of the file standardized?

The first split is not valid versus invalid. It is more useful than that:

• standardized exactly;
• standardized after a correction;
• could not be standardized; and
• contained no usable street address.

That separation matters because a corrected row and an unresolved row call for different action. A corrected row can go back into the working file with the standardized form recorded beside the original. An unresolved row needs research, confirmation from the source team, or suppression from the mailing.

The sample report matched 16 of 19 rows that actually contained an address: 13 exact and three corrected. Three could not be standardized, and one row was blank. The displayed 84.2% match rate uses the 19 address-bearing rows as its denominator. The blank row is reported separately instead of quietly improving or damaging the percentage.

That denominator discipline is part of the product. A quality percentage without its population is decoration.

2. Did a spreadsheet damage the ZIP data?

ZIP codes are identifiers, not numbers. Spreadsheet software still treats them like numbers often enough to strip a leading zero, drop a ZIP+4 suffix, or convert a mixed column into inconsistent types.

An audit should name those repairs rather than simply returning a five-character string. The report separates missing ZIPs from five-digit ZIPs and records ZIP repairs in the cleaning ledger. That creates a useful distinction:

• a present five-digit ZIP may be a complete value for the source file;
• a leading-zero repair is mechanical damage; and
• a missing ZIP is missing data, not a formatting error.

Operations teams can repair the first two automatically. The third needs address-level resolution.

3. Which rows become duplicates after cleaning?

Raw-text deduplication misses the duplicate that matters most: the same destination written two ways.

350 5th Ave and 350 Fifth Avenue do not compare equal as strings. A standardized address gives them a common comparison form. The report then groups the matching destinations into clusters and distinguishes all rows in a cluster from the redundant rows that can be retired after keeping one.

That last distinction prevents another common reporting error. A three-row cluster does not necessarily mean three wasted records; it means two redundant records if one row is retained. Cluster size and redundant-row count belong in separate columns.

The cleaned CSV keeps the row-level flag. The report shows the concentration of the problem, which is what a file owner needs to decide whether deduplication is a quick repair or a symptom of several systems feeding the same list.

4. Where is the file concentrated?

A file-level report should name counties and show their share of geocoded rows. This is not decorative geography. It answers practical questions:

• Is the file actually concentrated in the service area it claims to cover?
• Would a problem in one county affect a material share of the next mailing?
• Should a campaign or field team split the work by territory?
• Is an apparent national file mostly one metro area plus a long tail?

The denominator here is the geocoded population, not the raw row count. Rows without a usable coordinate cannot be assigned to a county honestly and should not be smuggled into an “other” bucket.

5. What does neighborhood context say—and not say?

For matched rows, the report can attach census-tract statistics such as median household income and housing vacancy. Those are neighborhood measurements. They do not say that a named donor earns the tract median or that a particular home is vacant.

Used correctly, the fields help a team understand its geographic footprint and prioritize verification in places where address churn may be higher. Used carelessly, they become false person-level claims. The report therefore names the geography, the source, and the matched-row count behind each distribution.

This is also why a file audit is different from a generic “enrichment” append. The purpose is to explain the quality and operating context of addresses the customer already owns, not to manufacture attributes about people.

6. When should the file be checked again?

A clean file is a dated result. People move, source systems diverge, and the address that was correct at the last event can be stale by the next annual appeal.

The report makes that decay visible as an estimate, not a fact about any specific row. It states the mover-rate assumption, shows the expected count at several horizons, and gives a re-run date for the point where the model expects a chosen share of the deliverable file to have changed.

The important words are estimate and assumption. The model is a planning clock for the file owner. It is not change-of-address processing, and it does not claim to know which household moved.

7. What did the cleaning pass repair?

The report carries a repair ledger for the changes already made:

• ZIP damage repaired;
• state names normalized to two-letter codes;
• whitespace and formatting repaired; and
• duplicate rows flagged.

This section is what makes the report usable in a board or client conversation. “We cleaned it” is difficult to defend. “Two ZIP values lost leading zeros, two state names were normalized, three formatting problems were repaired, and the standardized comparison exposed three duplicate clusters” is an auditable handoff.

The cleaned file still matters. The report does not replace it. One is the row-level working file; the other is the decision record for the whole file.

8. What do the bad rows cost under our assumptions?

A cost model should never arrive as an unexplained dollar figure. The sample exposes every input:

• postage per piece;
• print and material cost per piece;
• mailings per year;
• unresolved or blank rows; and
• redundant duplicate rows.

The model multiplies those assumptions into waste per mailing and per year. If the organization mails twice rather than four times, or if its production cost is higher, the result should be rerun with those numbers. The calculation is valuable because it is editable and attributable, not because one default estimate fits every mailer.

The decision the report should make easier

The report is finished when it creates an action queue:

1. verify or retire the rows that did not standardize;
2. repair mechanically damaged ZIP and state fields;
3. choose the retained record in each duplicate cluster;
4. review concentration and tract-level risk in the context of the mailing; and
5. set the next review date instead of letting the file age indefinitely.

If you only need a cleaned CSV under 10,000 rows, the smaller one-time product is List Clean. If the file needs a defensible report, the Address File Audit runs the full pass for up to 25,000 rows and returns both the cleaned CSV and the report. Open the sample report first; it is the fastest way to decide whether the report answers the questions your team will actually ask.

Method and product sources

• Public sample Address Quality Report, generated August 20, 2026
• Address File Audit product and upload contract
• RevAddress method, including the separation between standardization quality and CASS/NCOA processing