How to Validate ZIP Codes at the Front Desk in Altru

Pull a visitor-origin report at the end of the season and you will probably find ZIP codes like 00000, 99999, 1234, a Canadian postal code jammed into a five-digit field, and a surprising number of guests who all apparently live in the ZIP code of your own building. None of that is a cashier being careless on purpose. A line is forming, the guest mumbles, and the fastest thing to type wins.

Clean ZIP data matters more than it looks. Grant reports, tourism board surveys, county funding applications, and marketing decisions about where to advertise all lean on “where do our visitors come from.” So the goal is simple: get a real ZIP code into Altru at the point of sale, and catch the bad ones before they show up in a report someone else reads.

What to know about Altru’s own checks

Be careful about assuming Altru will reject a ZIP that doesn’t exist. In our experience, ZIP entry in daily sales behaves more like a text field than a lookup against a reference table: it may enforce a format, but it isn’t clear that it confirms a five-digit code is a real, assigned ZIP, or that it matches the city and state. Address validation features and settings can vary by account and change over time, so don’t take our word or anyone else’s as final.

To confirm what your instance does:

• In a sandbox or test environment, run a daily sales transaction and enter an obviously fake ZIP (for example, 00001) and a real ZIP paired with the wrong state. Note what is accepted.
• Check your organization’s address and constituent settings for any validation or address-processing options you may not have turned on.
• Ask Blackbaud support directly whether ZIP validation against a reference list is available for point-of-sale entry in your setup.

Whatever the answer, plan on a two-part approach: tighten what happens at the register, then audit what landed in the database.

Make the right entry the easy entry

Most bad ZIPs come from process, not software. A few changes at the desk do more than any validation rule:

• Ask the question the same way every time. “What’s your home ZIP code?” gets better answers than “Where are you from?”, which invites “Ohio” or “just visiting.”
• Give staff a sanctioned answer for refusals and non-US guests. If the only way to complete the sale is to type something, staff will invent a ZIP. Agree on a standard placeholder for “declined” and a separate one for “international,” and document both. A known placeholder is easy to filter out of reports; a random real ZIP is invisible.
• Ban your own ZIP as a default. Tell staff explicitly not to enter the venue’s ZIP unless the guest actually lives there. Then watch for it in the audit below.
• Read it back. Repeating the five digits takes two seconds and catches transposed numbers, which no format check will ever flag.
• Keep a printed list of nearby ZIPs at each register. Locals often know their town but not their ZIP. A short reference card for the surrounding area turns a guess into a real answer.

Audit ZIPs against a reference table

Since checking each entry against a master list at the register may not be possible natively, do it on a schedule instead. Weekly during your busy season and monthly the rest of the year is a reasonable rhythm.

1. Get a reference list. Download a current list of valid U.S. ZIP codes with their state and city from a public source, such as the Census Bureau’s ZIP Code Tabulation Area files or a USPS-derived dataset. Keep it in a spreadsheet you refresh once or twice a year.
2. Build an Altru query of recent daily sales. Pull transaction date, sales location or register if available, the user who entered the sale, and the ZIP (plus city and state if you collect them). Limit it to the period since your last audit.
3. Export and compare. In the spreadsheet, flag ZIPs that aren’t on the reference list, ZIPs that aren’t five digits (or ZIP+4), ZIPs whose state doesn’t match the entered state, and your venue’s own ZIP.
4. Look for patterns by user and register. One staff member with a run of identical or impossible ZIPs is a coaching conversation, not a data problem. Fix the habit and the data improves on its own.
5. Correct what you can, label what you can’t. If a transaction is tied to a constituent record with a good mailing address, update the ZIP from that. Anonymous walk-up sales usually can’t be fixed; mark them or exclude them from origin reporting so they don’t skew results.

Save the query and the spreadsheet comparison as a reusable template. After the second or third run, the audit should take minutes rather than an afternoon.

Handling visitors from outside the U.S.

International guests are where most ZIP fields break down. Canadian postal codes, U.K. postcodes, and others won’t fit a five-digit pattern. If your setup lets you record country, capture that and leave the ZIP blank or use your agreed international placeholder. If country isn’t practical to collect at the desk, the placeholder alone still lets you count international visitors honestly instead of losing them among fake U.S. codes.

Reporting on cleaner data

Once the audit is in place, build your visitor-origin reports to exclude the declined and international placeholders, or show them as their own categories. Funders tend to trust a report that shows how many visitors declined to share more than one where every visitor conveniently has a valid ZIP. Being upfront about the gaps is part of what makes the rest of the numbers credible.

Quick answers

Can I make ZIP a required field at the front desk?
Possibly, depending on your configuration, but test it first. Requiring a field without giving staff a valid “declined” option tends to produce more fake ZIPs, not fewer.

Should we collect full addresses at the register instead?
Usually not for walk-up admission. It slows the line and guests are more likely to refuse. ZIP alone is enough for origin reporting; collect full addresses for memberships and donations, where you actually need them.