Create a data dictionary for a small business team
Define important business fields, identifiers, dates, statuses, sources, and calculated measures with a readable data dictionary and worked example.
A data dictionary explains what the fields in a business record mean, how values should be entered, and who decides when the definition changes. It is useful when one team’s active customer means something different from another team’s active customer, when a date column changes meaning between exports, or when a blank value could mean either unknown or not applicable.
Small businesses do not need an elaborate cataloging platform to solve those problems. A maintained document or spreadsheet can provide a shared reference for the records that drive everyday decisions. The important part is agreement about meaning, not the number of fields documented.
This guide offers an original method for building a practical dictionary around one business process. It includes a hypothetical order record, a reusable field specification, and a controlled way to change definitions. It does not assume that your software can enforce every rule automatically.
Begin with one decision and its underlying records
Choose a decision that repeatedly causes confusion. Perhaps the team cannot agree which projects are ready to invoice, which customers need a follow-up, or whether a delivery is complete. Work backward from that decision to the fields people rely on.
This keeps the first dictionary manageable. Documenting every field in every application is a large project with little immediate value if the important meanings remain disputed. Start with the handful of fields that determine the selected action, then expand when the team can maintain the reference.
The UK Government Data Quality Framework treats quality as fitness for an intended purpose and emphasizes understanding users’ needs. Its government context is different from a small business, but that limited principle is useful here: define the decision before judging whether the data is good enough to support it.
Distinguish business meaning from a software label
A label such as status is rarely a complete definition. Explain whose status it is, which business event changes it, and what action each value permits. A project can be commercially complete while administrative evidence is still missing. Combining both ideas in one done checkbox creates ambiguity.
Give the business concept a plain-language name, then record the actual field names used in each system. Your website may call it customer_reference while the finance export calls it account_code. A dictionary should make that relationship explicit rather than forcing everyone to remember it.
Use examples and counterexamples. Ready to invoice might mean that delivery evidence has been reviewed and the agreed billing conditions have been checked. It should not mean that a team member thinks the work is probably finished. The business handoff checklist shows why a clear readiness definition matters when records move between teams.
Use a field specification people can read
For each important field, capture enough information to prevent the most likely mistakes. Keep technical detail proportionate to the audience. A colleague entering information should understand the rule without needing to interpret a database schema.
| Dictionary item | What to write | Example for an order record |
|---|---|---|
| Business name | The concept people recognize | Order reference |
| System field | Actual column or property name | order_reference |
| Definition | What the value identifies | One accepted order, not a customer |
| Format | Expected structure or type | Text with the original leading zeros |
| Allowed values | Valid choices or constraints | Unique within the order register |
| Empty-value meaning | What a blank represents | Not permitted after acceptance |
| Source | Where the value originates | Authoritative order register |
| Owner | Who decides the definition | Operations owner |
| Consumers | Who relies on the field | Dispatch and finance |
Add a realistic example and a known invalid example. These are particularly valuable for identifiers, dates, amounts, and status fields. Use invented data in the dictionary rather than copying confidential customer records into a widely shared reference.
Define identifiers before descriptive fields
An identifier answers which record you mean. A name answers how people recognize it. The two serve different purposes. Customer names can change, two people can share a name, and a company can have several trading names. A stable reference helps the team connect records without relying on a label that may be ambiguous.
Document where an identifier is created, whether it can change, which system owns it, and how related systems store it. Do not assume that a numeric-looking reference should be treated as a number. Leading zeros and punctuation can be meaningful parts of an identifier.
Include relationship rules. Does an order reference point to exactly one customer record? Can one project have several invoices? What happens if the referenced record is unavailable? These questions matter during exports and imports. The CSV import checklist builds on the dictionary by checking that incoming values preserve the intended identity and relationships.
Make dates, amounts, and empty values unambiguous
Specify what each date represents: request received, order accepted, work completed, invoice issued, or payment confirmed. Record the time zone for timestamps where timing matters. A report that mixes local time and an external system’s time can put an event on different calendar days.
For monetary values, identify the currency and whether the field contains a net, tax, gross, refunded, or outstanding amount. Avoid a generic amount field whose meaning depends on the person reading it. Accounting treatment and tax requirements belong with the qualified person responsible for those decisions.
Define empty values explicitly. Unknown, not yet collected, not applicable, and intentionally withheld are different states. You may not need a separate field for every distinction, but the chosen representation should be documented. An empty delivery date must not quietly become evidence that an order was never delivered. The dictionary should prevent assumptions from filling gaps in the underlying record.
Turn status words into controlled transitions
Status fields often deserve a small table of their own. For each allowed value, describe the entry condition, the person or process allowed to set it, the evidence required, and the next permitted states. Keep the list small enough to use consistently.
For a simple service request, the team might use received, awaiting information, ready for work, in progress, awaiting review, and closed. Closed needs a definition: does it require a completed response, a recorded cancellation, or an approved exception? If those outcomes differ operationally, record the outcome separately.
Avoid making one status carry unrelated meanings such as payment state, customer sentiment, and delivery progress. Separate fields are often clearer than increasingly complicated combined labels. If you introduce a new value, identify which reports and actions rely on the old list before changing it. A new status that nobody’s filter includes can make valid work disappear from a queue.
Record authority when systems disagree
Different systems may hold different versions of the same concept. Decide which source is authoritative for each field and what should happen when values conflict. There may be no single system that is authoritative for the entire customer record.
For example, the order register may own the accepted order reference, the delivery record may own dispatch confirmation, and the finance system may own payment reconciliation. Document those responsibilities instead of declaring one application the source of truth for everything.
Record the direction and timing of updates where information is copied. A nightly export is not the same as a current value. Include a last-updated timestamp or an explanation of expected delay when readers need it. If information conflicts, identify the person who investigates and the evidence they should compare. The duplicate customer record guide addresses a related problem: deciding whether apparently similar records represent the same real entity.
A hypothetical dictionary for dispatch readiness
Imagine a small retailer whose support team tells customers that ready orders will ship today. The warehouse uses ready to mean picked, while support uses it to mean payment received. The same word therefore produces conflicting promises.
The owner introduces three distinct fields: payment_confirmation, picking_state, and dispatch_commitment. The dictionary states who owns each field and what evidence supports it. Dispatch commitment is not populated merely because payment is confirmed; the warehouse must assess the operational conditions it controls.
The first version includes invented examples of an order with payment confirmed but stock unresolved, and an order picked but held for an address check. Those counterexamples help colleagues see why the fields are separate. The owner also records that the support team may report the commitment but may not manufacture it from other fields.
This is a hypothetical design exercise, not a measured case study. Its value is the removal of an ambiguous word from a decision path. The team can now test whether its actual process supplies the required evidence rather than arguing about what ready was intended to mean.
Validate definitions with actual users
Ask one person who enters the data and one person who uses it to work through a few examples. Give them the dictionary without an oral explanation. If they reach different conclusions, revise the definition or the underlying process.
Include unusual but plausible cases: a customer changes their name, an order is split, an item is partially returned, or a project is reopened. Do not document only the ideal path. A dictionary becomes useful when it explains how to represent real variation without inventing new meanings in each row.
The W3C CSV on the Web primer explains how metadata can describe columns, types, and constraints for tabular information. You do not need to implement its technical vocabulary to benefit from the distinction between raw values and the rules that explain them. Keep your first dictionary readable, and involve a technical specialist if you later need machine-enforced validation.
Manage changes without silently rewriting history
Assign a dictionary owner and record a version date. When a definition changes, state what changed, why, who approved it, and when the new meaning takes effect. Decide whether historical records keep their original meaning or need a reviewed conversion.
Avoid quietly replacing a status definition after reports have already used it. A trend can appear to improve simply because the underlying classification changed. Mark the transition so readers can interpret comparisons honestly. The change record should also identify forms, exports, reports, and procedures that require updates.
Keep proposed changes separate from approved definitions. A colleague can suggest a useful new field without making it an immediate operating rule. Review whether the field supports a real decision, who will maintain it, and what happens if it is empty. Removing an unused field can be as valuable as adding one, especially when it collects unnecessary customer information.
Keep translations and display labels separate from stored meaning
Businesses serving several countries may display the same concept in different languages or date formats. Record the underlying meaning independently of that presentation. A translated label should not create a second operational definition unless the business deliberately needs a different concept.
For example, a display may show a friendly local status while an export uses a stable internal code. Document the relationship and identify who maintains it. If a colleague renames the visible label, check whether reports rely on the code or the label before approving the change.
Also document units. A duration of two is meaningless without knowing whether it represents hours, days, or working days. A weight field needs its unit and a rule for conversion. These details often matter most at a handoff, when the recipient cannot see the assumptions that were obvious to the person who entered the value. Include a simple counterexample showing the consequence of using the wrong unit, and test it with the team before relying on a conversion.
Document calculated measures as well as input fields
A dashboard measure needs a definition too. Write down which records it includes, which it excludes, the relevant date, the calculation, and the person who owns the interpretation. A figure called completed projects can change depending on whether it counts delivery, customer acceptance, or administrative closure.
Give the measure a worked example using invented values. For instance, show three projects with different states and explain which ones count in this report. Include a reopened project so the team can decide whether it belongs in the original period, the current period, or a separately defined view. The dictionary should make that decision explicit rather than letting a spreadsheet formula settle it by accident.
Also record when the measure is refreshed and whether late corrections change historical totals. Readers need to know whether yesterday’s figure is a stable snapshot or a live recalculation. Keep the definition close to the dashboard, using a short label with a link or reference to the fuller explanation. That makes the dictionary useful at the moment someone asks what the number means. A shared calculation can then support a business decision instead of producing a precise-looking figure with several competing interpretations.
Measure whether the dictionary reduces confusion
Start with a short pilot around the chosen decision. Note the questions people ask before the dictionary exists, then observe whether the written definitions answer them. Track unresolved conflicts, invalid entries, and the time needed to interpret an unfamiliar record. Do not assume that simply publishing the document changes behavior.
Useful pilot questions include: can a new colleague identify the authoritative field? Can two people classify the same example consistently? Can the team explain why a record is not ready for the next step? These checks are more meaningful than counting how many pages the dictionary contains.
Keep the dictionary near the work it supports and link to it from relevant procedures. Review it when a form, report, or system changes. Begin with a dozen important fields if that is what the team can maintain. A small reference with clear ownership can make business records understandable; a large abandoned catalog merely adds another source of uncertainty.
Sources and editorial method
Checked October 15, 2026. Primary references: UK Government Data Quality Framework and W3C CSV on the Web primer. The article draws only limited principles about purpose, metadata, and constraints from these sources. The field specification, review method, dispatch example, and pilot questions are original guidance. The example is hypothetical and does not imply that any particular application or automated validation has been tested.
