Start with the purpose of the data
A customer list, project tracker or sales spreadsheet can look tidy while still containing problems that affect decisions. A blank project completion date might make work appear unfinished. Two records for one customer might inflate a count. An unusually large invoice might be an entry error—or a genuine job. Checking data helps you tell these situations apart before you use the numbers.
Begin by naming the decision or report the data supports. If you want to count active customers, you need a clear definition of “active” and a reliable way to identify each customer. If you want to compare project durations, you need consistent start and finish dates. Keep an untouched copy of the original file, then work on a separate version. That gives you a way to review or reverse any changes.
Find missing values and decide what they mean
Check important columns for empty cells, placeholder text such as “unknown,” and values that may stand in for missing information. A zero is not always a missing value: zero hours billed could be correct, while a zero in a project start-date field would not be a usable date. Filter each column or use a spreadsheet count to see how many records need attention.
Treat missing values according to their role. If a customer email is blank, you may still be able to count that customer, but you cannot use the record for an email contact list. If a project’s finish date is blank because the project is ongoing, label its status rather than inventing a date. Where possible, check the original invoice, form or project record to fill a gap. If you cannot verify a value, leave it marked as unknown and note which calculations exclude it. Replacing blanks with guesses can make a report look complete while making it less trustworthy.
Identify duplicates without merging different records
Duplicates are records that represent the same thing more than once. First decide what one row is supposed to represent: a customer, a purchase, an invoice or a project. Repeated customer names may be expected in a sales table containing one row per purchase. Repeated invoice numbers, by contrast, may need investigation if each invoice should have a unique number.
Look for exact matches using a stable identifier, such as an internal customer ID or invoice number. Then review likely matches that differ slightly: “North Street Studio” and “North St Studio” could refer to one customer, but similar names alone are not proof. Compare other details, such as contact information or project history, before merging. If you find two versions of one customer record, decide which details are verified and keep a record of what you combined. Delete a row only when you are confident it adds no distinct information.
Review outliers as questions, not automatic errors
An outlier is a value that stands apart from most others in a set. In a list of project fees, one amount might be much higher than the rest. Sort numeric columns from smallest to largest and scan for values that seem implausible in context. Simple summaries, including the minimum, maximum and typical range, can help you focus your review. Check dates too: a finish date before a start date is a useful signal even if both cells contain valid dates.
Investigate unusual values against the source record. A fee of 15,000 entered instead of 1,500 may be a typing mistake. A large fee for a long, complex project may be entirely correct. Fix a confirmed error, but keep a valid outlier; removing it solely because it is unusual can distort the picture. If an exceptional project makes an average less representative, you can show a median or describe the exception alongside the summary.
Create a repeatable checking routine
A useful routine can be short: confirm what each row represents, check required fields, search for duplicate identifiers, scan key numbers and dates for unusual values, and verify flagged records against their sources. After making corrections, repeat the checks. For a recurring report, apply the same definitions each time so changes in the results are less likely to come from changes in your method.
Keep a brief change log that records what you corrected, what remains uncertain and any records excluded from a calculation. For example, note that a project-duration summary excludes projects without a verified finish date. Share only the data colleagues need for their work, particularly when records contain customer contact details. The goal is not a spreadsheet with no blanks or unusual numbers; it is data whose limitations you understand well enough to use responsibly.
