# Receipt scanning is not the same as accounting

Companion to /learn/keywords/research-process/

## Outcome
Build a defensible keyword map from product evidence, search intent and prioritisation.

Fictional example, not a client result.

## Scenario
SlipKeep is a fictional receipt organiser for self-employed people. It scans receipts and exports records, but it does not calculate tax or run payroll. A research tool returns attractive ideas for all three jobs. The team is tempted to include every business-related term because the category feels close enough.

## Reasoning
Begin with the supported workflow and collect the language customers use to describe it. Group candidates by the job behind the query, then annotate product fit, locale, source and uncertainty. Research estimates can help compare candidates within a consistent context; they cannot make an unsupported intent relevant. Preserve rejected terms with reasons so the next stakeholder does not reintroduce them without new evidence.

## Action
Create clusters for receipt scanning, receipt storage and expense records. Hold broader expense-management terms for product verification. Reject payroll and tax-filing promises unless the app genuinely supports them. Draft metadata from the selected clusters, then review whether the visible listing explains the same job. A technically neat keyword map is incomplete if the creative tells a different story.

## Trap to avoid
Do not deliver a spreadsheet of phrases without decisions. The team needs to know which terms are relevant, which require validation, which were rejected and how the selected clusters should influence copy. Export size is not research quality.

## Advanced considerations
Use versioned research snapshots. A later reviewer should be able to reconstruct why a term was selected even if tool estimates change. When results are disappointing, review the original intent and product-fit assumptions before swapping in another high-volume phrase. Search behaviour, discoverability and listing choice are different questions; a ranking report cannot answer all three.

## Exercise
Two keyword tools disagree about the demand for “receipt organiser.” Which estimate should you put in the brief?

## Suggested answer
Record both sources, dates, markets and scales rather than averaging incompatible scores. Use the disagreement as uncertainty. Inspect relevance and surrounding search context, then choose a defensible priority without pretending the estimates are exact store counts.

## Your worksheet

### Candidate phrase and locale
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Underlying job or intent
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Product support and screen evidence
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Source, collection date and estimate definition
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Cluster and priority rationale
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Metadata destination and review condition
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

## A populated keyword map you can reproduce
The entries below continue the fictional SlipKeep example. They are editorial candidates, not observed search demand. No search-volume or difficulty scores have been invented. Each row states what the researcher should verify before handing it to a writer.

Fictional candidate map. Product assumptions are illustrative; demand is not measured.
Candidate / intent | Product evidence and uncertainty | Disposition and handoff
Receipt scanner / capture a purchase record | Capture workflow exists; verify the audience’s local terminology | Core candidate; connect copy to a real capture screen
Receipt organiser / retrieve stored receipts | Storage and retrieval exist; demand remains unmeasured | Research candidate; inspect search context and user language
Expense report / prepare a submission | Export exists, but approval and reimbursement do not | Hold; clarify the expected workflow before writing
Tax filing / submit a tax return | App does not perform filing | Exclude; retain reason in the research record
Payroll / calculate and pay staff | App does not perform payroll | Exclude regardless of apparent popularity

### Collect evidence in an order that reduces waste
Start with a product walkthrough and a short list of supported jobs. Next collect customer language from available interviews, support themes or reviews, noting the source and date. Use search observations and tools to expand the candidate set after establishing those boundaries. This reduces the chance of spending hours scoring phrases for a workflow the app does not offer.

### Resolve disagreement without averaging incompatible scores
If sources disagree, check market, date, spelling, scale and methodology before comparing their estimates. Keep the original values and sources in separate columns. Do not average a popularity index with a different tool’s difficulty score. A candidate with uncertain demand may still deserve investigation, but the brief should say exactly which uncertainty remains.

### What the writer should receive
Deliver the priority intent group, the customer job, approved product evidence, appropriate store-field destinations, exclusions and unresolved questions. Include a sample message direction rather than forcing the writer to reverse-engineer the research. For receipt capture, a direction might explain capturing and organising receipts; it should not promise a completed tax return. Check the final draft against this map before publication.

## Continue reading
- /learn/keywords/search-intent/
- /learn/keywords/prioritization/
- /learn/ios/keyword-field/