A file with five hundred rows does not necessarily contain five hundred companies. It might contain one hundred companies with five contacts each, several rows for the same person, or a mixture of parent organizations and branches. Before comparing prices or importing a list, establish what each number counts.
Company quantities and contact quantities answer different business questions. The first describes account coverage; the second describes people available within those accounts. This guide provides a counting model, a five-company worked example, and practical reconciliation steps. All company names and numerical scenarios are fictional teaching examples, not claims about a delivered customer order.
What you’ll be able to do
- A company count needs an explicit account boundary and a stable company identifier.
- Count distinct people separately from contact rows, email addresses, and company-contact relationships.
- More contacts at the same company do not expand the number of companies covered.
- A completed new lead and an enriched existing record can have different contact requirements.
- Reconcile the company table, contact table, and their associations before relying on a spreadsheet row count.
Keep four counts visible
Start with four totals: distinct companies, distinct people, contact rows, and company-contact associations. These totals can differ for legitimate reasons. One person may hold roles at two companies; one company may have several people; one person may have two observed email addresses. A row count is only meaningful after the file structure is explained.
For purchasing, ask which total defines the quoted unit. If the order is for one hundred companies, two contacts at one company do not make two purchased companies. If a vendor uses a person-based model, the opposite issue arises: a large number of contacts can cover a much smaller account universe than the buyer expects.
Write the labels in the order summary itself. “100 companies, contact coverage according to accepted scope” is clearer than “100 leads” when the word lead has not been defined. Retain the supplier's definition alongside your internal terminology so finance, operations, and sales do not reinterpret the same invoice differently. This is a counting convention to agree, rather than a universal industry definition.
Define the purchase unit Put company and contact definitions into the accepted campaign specification.
Choose the company boundary before deduplication
A company boundary determines what counts as one account. Your campaign might work at the legal-entity level, the operating-business level, or a brand level when brands have distinct teams. The correct choice depends on the commercial work you plan, but it must be consistent.
Imagine a group with a central office and three regional locations. If one team purchases the service for all locations, treating each address as an independent account may overstate coverage. If separate subsidiaries operate independently, merging them solely because their names share a parent brand may erase useful account distinctions. Capture relationships instead of forcing every related business into one record.
A domain can help identify accounts, yet a domain is still an attribute rather than a complete identity policy. Shared sites, regional domains, rebrands, and hosted storefronts require interpretation. Preserve the observed website and a canonical company identifier. For ambiguous cases, retain a reason and review status. Do not silently merge records because a convenient text-cleaning rule makes the totals look tidier.
The five-company specimen
The following fictional specimen deliberately contains uneven contact coverage. Alder has three people, Birch has one, Cedar has no usable named contact, Delta has two, and Elm has one. The company population is five throughout. Adding a second address for Alder's founder would create another address record, not another person or company.
Notice Cedar's state. If this were an order whose completion rule required a named contact with business email for each new company, Cedar would not count as a completed new lead merely because its company profile was detailed. If it were an accepted own-list research task, Cedar could still be a researched company with a clearly documented contact limitation.
The table is useful because it makes the denominator visible. “Seven contacts” says little about coverage until you see their distribution across five companies. Four companies have at least one person, while one has none. A sales manager can now decide whether account coverage or additional people within existing accounts is the next research priority.
| Company ID | Fictional company | Distinct named people | Company state |
|---|---|---|---|
| C-01 | Alder Systems | 3 | Named business contacts present |
| C-02 | Birch Studio | 1 | Named business contact present |
| C-03 | Cedar Works | 0 | Company researched; contact unresolved |
| C-04 | Delta Supply | 2 | Named business contacts present |
| C-05 | Elm Analytics | 1 | Named business contact present |
Calculate coverage with the right denominator
In the specimen, the average number of named people per company is seven divided by five, or 1.4. The fraction of companies with at least one named person is four divided by five, or 80%. Those are different measures. The average can rise when Alder receives more contacts while Cedar remains uncovered.
Add a distribution to avoid hiding concentration. Record how many companies have zero contacts, exactly one, and more than one. For a campaign seeking a first relevant entry point at every account, zero-contact companies deserve attention before adding a fourth contact at an already covered account. A campaign intentionally researching several buying roles may have a different priority.
Keep role coverage distinct from person coverage. Three named people do not establish coverage of three needed functions. They might all work in the same department or have unclear responsibilities. If the planned approach needs an operating owner and a technical evaluator, use two role-specific columns with evidence states. Do not inflate the count by assigning several inferred role labels to a single public title.
The resulting dashboard should explain its population and date. Counts calculated before suppression or identity review should not be compared with counts calculated after those processes without identifying the change. Otherwise a legitimate reduction in usable accounts can look like missing delivery.
Worked example: reconciling a new company order
A fictional buyer orders one hundred new companies. The delivery contains a company file with one hundred IDs and a contact file with 146 rows. The buyer's first reaction is that the supplier delivered forty-six bonus leads. That interpretation is premature.
Operations finds 139 distinct people because seven contact rows represent alternate addresses. Those people are associated with ninety-eight company IDs. Two companies lack the required named founder or administrator business email. Another company has a contact associated with the wrong organization, so its completion state also needs review even though a populated email cell exists.
The buyer reports one hundred delivered company records, ninety-seven companies meeting the current contact-linkage check, 139 distinct people, and 146 contact rows. These figures identify the work needed without declaring that all forty-six extra rows are either valuable or defective. The three unresolved company cases are returned with their IDs and specific reasons.
After correction, the company total remains one hundred. Contact rows may increase, decrease, or remain the same depending on the fix. The accepted company quantity should not be changed merely to make it match the contact sheet. The buyer archives both versions and a correction ledger so later importing staff can tell which associations were replaced.
Test company completion explicitly Use independent identity, contact, and association checks rather than one aggregate row count.
Worked example: enriching an existing list
A different fictional buyer supplies 120 rows from an old account spreadsheet. Ten rows repeat domains already present elsewhere, five contain names without a resolved website, and two regional brands share a corporate website. The buyer wants company context and intends to preserve all original row identifiers.
The researcher should not simply return 103 rows and call the job cleaned. First establish the accepted processing unit. There may be 120 input rows, a smaller set of distinct research targets, and some unresolved matches. The return file needs a mapping from each input row to the relevant output company or an unresolved status.
Suppose two input rows are aliases of one confirmed company. Both input IDs can point to the same company ID without creating a second researched business. Conversely, the two brands sharing a website may remain distinct operating accounts if the agreed evidence supports that distinction. A single domain-level deduplication rule cannot settle both situations correctly.
Because this is an own-list order, additional new contacts are not guaranteed. The company research can still be useful if the existing contact fields are preserved and new findings remain distinguishable. The acceptance report should separate records processed, companies researched, matches unresolved, and contacts supplied or retained. Those counts explain the transformation the buyer actually purchased.
Do not confuse a person with an address
A contact record should represent a person in a business context, with the evidence available for the name, role, organization, and address. Treat an email address as one attribute of that record. A changed address does not automatically mean a different person, and a shared mailbox does not automatically identify a named person.
Avoid using the full name alone as a definitive matching key. Different people can share a name, while the same person can appear with initials or a changed surname. Combine the available company association, role evidence, and other accepted identifiers. When the evidence does not support a confident merge, retain the ambiguity instead of making the file appear cleaner than the underlying research.
Keep role history separate from current affiliation where history matters. If a public page identifies someone as a former employee, do not count that relationship as current company coverage. Likewise, a person advising several businesses may have several associations without being an employee of each. The count should reflect the relationship relevant to your campaign.
Do not derive new email variations merely to increase the number of contact rows. A list with more guessed addresses can look richer while becoming harder to review. Ask what the address status means and what evidence supports the person-to-company link.
Represent associations as first-class information
A useful data model has a company table, a person table, and a way to connect them. Small deliveries may flatten that structure into a spreadsheet, but the logical relationship still exists. Include the company ID on every contact row so an importer does not have to infer the relationship from similar company names.
If one person legitimately relates to two companies, preserve two associations with their own role descriptions. Do not duplicate the entire person record without explanation. When the delivery format cannot represent multiple associations cleanly, ask for an association sheet or a clearly documented repeated-row convention.
Make broken links easy to detect. Every contact company ID should exist in the company table. Every association should have a stated meaning such as current founder, administrator, or another observed business role. A contact row with a plausible name and email but no reliable organization link should enter review.
The W3C's tabular data model describes relationships between tables through keys. The practical recommendation here is narrower: make company-contact links explicit enough that a reviewer can test them before import. You do not need to adopt a complex database system to gain the benefit; consistent identifiers in a well-defined workbook can support the same basic checks.
References: W3C: Model for Tabular Data and Metadata on the Web ↗
Compare prices at the same level
Normalize quotes to the accepted company unit before evaluating apparent cost. A quote for one hundred companies and a quote for one hundred contacts cannot be compared by dividing both totals by one hundred and calling the results equivalent. The second quote may cover far fewer accounts.
Also compare completion rules. A company record without a named contact may be acceptable in a market mapping project and incomplete in a new lead purchase. Research depth matters too. A basic list, a general company brief, and an offer-specific dossier require different outputs and support different decisions.
For StackShortlist, the starting price for one hundred new companies is $19 for Stack leads, $39 for Company intelligence, or $79 for Your-offer intelligence. The corresponding own-list starting prices are $15, $35, and $69 per one hundred, with a minimum of one hundred. Each requirement after the first adds $0.10 per company under either All or Any matching. Payment is taken at checkout.
Do not infer guaranteed contact multiplicity from those company prices. Completed new leads require a named founder or administrator with business email, while phones are optional. Record any further contact expectations in the accepted scope. A count that exceeds the minimum requirement is still worth inspecting for relevance and correct associations.
Normalize quotes before comparing them Align counting units, completion rules, and research depth before evaluating price.
Run a reconciliation in a fixed order
Begin with an untouched copy of the delivery and a separate working copy. Record the received filenames and version. Count raw rows first, but label that figure as raw rows. Then count distinct company IDs and inspect blank or repeated identifiers.
Next review company identity and group relationships. Only after the company set is stable should you count contacts and associations. Otherwise a merge can change the denominator halfway through the analysis. Keep an exception table with company ID, input row ID where applicable, issue type, evidence, and requested correction.
Calculate contact coverage using the agreed completion requirement. A populated contact-name field is not sufficient if the business email or company association is missing. Record optional phones separately so their absence does not incorrectly reject an otherwise completed record.
Finally compare the reconciled totals to the accepted quote and specification. Explain differences as categories rather than one unexplained variance. For example: duplicate input aliases consolidated, unresolved identity retained, contact association corrected, and optional fields blank. The goal is an auditable bridge from the purchased unit to the files the team will use.
Inventory the files
Preserve originals and note version, raw rows, and stated record unit.
Resolve the company set
Check identifiers, duplicates, group relationships, and unresolved identities.
Reconcile people and links
Count distinct people, company associations, and company-level contact coverage.
Publish exceptions
Report the exact IDs and reasons behind any difference from the accepted scope.
Diagnose suspicious totals
If the contact count rises sharply but company coverage does not, examine whether the delivery concentrates many people in a few easy-to-research accounts. That may be useful for a multi-role campaign, but it does not solve missing coverage elsewhere. Request the distribution before deciding whether the additional contacts add value.
If the company count falls after normalization, inspect each merge category. Removing repeated capitalization variants is different from merging subsidiaries. Keep the original aliases so the team can trace the change. A merge log should show the retained company ID and the reason each removed identifier points to it.
If importing creates more companies than the delivered count, check whether contact rows caused new account creation because company identifiers were missing or mapped incorrectly. If importing creates fewer, inspect duplicate rules and any domain-based merges. Neither outcome should be attributed to supplier quality until the transformation has been examined.
If several people share one address, avoid counting that address as independent named-person coverage without reviewing the field definition. The important question is whether the data supports the required person and organization relationship, not whether the spreadsheet contains enough nonempty cells.
Write a counting policy the team can reuse
Create a one-page policy with the company boundary, person identity rule, association meaning, completion requirement, and treatment of unknowns. Include the five-company specimen or a similar internal teaching example. A short worked example helps colleagues see why several correct counts can coexist.
Assign ownership of the policy to the person responsible for data acceptance. Sales can explain the campaign need, finance can check the quoted unit, and operations can verify the import. One owner should resolve competing definitions so the same order is not accepted under three different counting systems.
Version the policy when the campaign changes. Moving from independent businesses to enterprise subsidiaries is a substantive account-boundary change. A new buying-role strategy can change what contact coverage means. Retain the earlier version with previously accepted orders rather than recalculating historical totals using today's rule.
Use the reconciled company count as the basis for account planning, and use role coverage to plan additional research. This preserves the difference between reaching more organizations and understanding existing organizations better. Both can be valuable, but they are separate choices and should remain separate in the budget, the order, and the team's reporting.
Common questions
Can one company legitimately appear on several rows?
Yes. A flattened file may repeat company fields once for each contact or office. The repeated rows should share a stable company identifier, and the data dictionary should explain the convention. Count distinct company IDs after identity review rather than assuming every row is a new company.
Is an email address the same as a contact?
Not necessarily. One person can have multiple addresses, while a shared mailbox may not identify a person. Keep person identity, address status, and company association distinct. This allows you to understand whether additional rows expand account coverage or merely add another way to reach an already known person.
Should a parent and subsidiary count separately?
That depends on the accepted account boundary. If the campaign addresses independent operating entities, separate records may be appropriate. If the work is purchased centrally, group-level planning may be more useful. Preserve ownership relationships and explain the choice instead of allowing a deduplication shortcut to decide it.
What should I report when some companies lack contacts?
Report the company total, the number meeting the agreed contact requirement, and the unresolved cases with reasons. Do not erase researched companies from an own-list result simply because contacts are missing, and do not label an incomplete new lead complete when its required contact coverage is absent.
Does a larger contact count mean a better list?
Only if the added contacts support the intended campaign. Several relevant roles at one strategic account can be valuable. Many unverified or redundant people at the same account may add review work without improving coverage. Evaluate distribution, role evidence, and association quality alongside the total.
Sources & further reading
Primary references support the technical details. Worked examples are illustrative; workflows and checklists are practical methods to adapt to your own process.
Something changed? Tell the editorial team.