One of the first questions new AlignMix users ask sounds simple: what’s the difference between account data and ZIP code data, and which one should I import? The answer shapes how your whole alignment behaves, so it’s worth being precise.
The Short Answer
ZIP code data describes places. Account data describes customers. A ZIP-level metric (population, business count, total market potential) belongs to the geography itself, so every territory that owns the ZIP owns that value. An account record belongs to one specific customer at one specific location, with its own identity, its own revenue, and possibly its own rep, no matter which ZIP it sits in.
ZIP Code Data: The Geographic Layer
ZIP code data attaches one row of metrics to each ZIP, think market potential, demographic counts, aggregated sales. Assign a ZIP to a territory and all of its data comes along. This layer answers the design questions: how much opportunity does each territory hold, and are territories balanced?
Use ZIP-level data when the individual customer doesn’t need separate handling and aggregate opportunity is what you’re balancing. It’s also the natural home for external data like census demographics and business counts, which are published by geography, not by customer. (More in our guide to ZIP code boundaries.)
Account Data: The Customer Layer
Account data is one row per customer: ID, name, address or ZIP, revenue, segment, current rep. Accounts show up as individual points on the map, sized or colored by value. This layer answers the management questions: which specific customers change hands in this realignment, where are my key accounts concentrated, which rep owns this hospital?
Account data is what makes disruption measurable, because you can count exactly which accounts and how much revenue move between reps in any scenario. It’s also where account overrides live: a specific account assigned to a different rep than its geography would give it.
Why the Two Layers Stay Separate
Here’s the subtle part. In AlignMix the two datasets are imported separately and can disagree, on purpose. An account physically inside Territory 4’s geography can belong to Territory 9’s rep, for a legacy relationship or a national account. The ZIP still belongs to Territory 4; the account carries its own override. Keeping the layers separate keeps the geographic design clean while real-world exceptions stay documented and reportable, instead of being smuggled in by distorting ZIP assignments.
Which Should You Import?
Both, usually. The practical pattern is ZIP-level data for opportunity and balance, account-level data for customers and disruption. If you only have one, use account data when your business concentrates in identifiable customers (B2B, medical, key accounts) and ZIP data when your market is broad and diffuse (consumer services, retail coverage). Our data requirements guide covers how to prepare each file.
Watch: Account Data vs. ZIP Code Data
Frequently Asked Questions
Can an account be assigned to a different territory than its ZIP code?
Yes, that’s an account override. The ZIP keeps its geographic territory while the specific account is owned by another rep. Overrides are the right way to handle exceptions without distorting the map.
Do I need account data to balance territories?
No, ZIP-level opportunity data is enough for balancing. But without account data you can’t measure disruption, which customers change reps, so realignments get harder to sell internally.
How do I import each type into AlignMix?
Separate Excel imports: a ZIP-level sheet (one row per ZIP) and an account sheet (one row per account). Each can be updated on its own without rebuilding the alignment.
See both data layers on one map. Try AlignMix free or book a demo.