Manual Data Entry Examples, and What Each One Costs You

Most manual data entry examples come down to one thing: someone typing information into a system when it already exists in another. The typing is the cost everyone sees. The errors cost more, and you can measure them this week. Export 50 records created last month from both systems, line them up on the shared ID, and count the fields that disagree with one spreadsheet formula per column pair, such as =SUMPRODUCT(--(TRIM(B2:B51)<>TRIM(C2:C51))). Put that count through the cost arithmetic below and "is it worth fixing?" becomes a number.

1. Re-keying a record from one system into another

What it looks like: an order is entered in the sales system, then typed again into the operations or accounting system.

The error it produces: two kinds of divergence that look identical in a report. Typing errors happen at entry. Amendments happen later, when a change reaches one system and not the other. If a mismatched record was edited after it was first keyed (compare last-modified dates), it is an amendment, and careful typing would not have prevented it.

Cheapest removal: run the 50-record test first, because the fix depends on which kind dominates. Typing errors on a weekly batch go away when the batch goes through the destination system's import tool, such as Salesforce's Data Import Wizard (see what you already pay for). Amendments only go away when one system owns each field and the other receives it; the field ownership table in our guide to connecting business systems settles that.

2. Typing an instruction from email into a system

What it looks like: a customer writes "can you make Thursday's delivery 12 instead of 10 and send it to the Elm Street site", and someone updates the order.

The error it produces: the system keeps the interpretation and loses the instruction. When the customer disputes the delivery, the only proof is in one person's mailbox.

Cheapest removal: three moves, in this order.

Keep the original with the record. Attach the message itself (an Outlook .msg or a standard .eml file) to the order, not pasted text. Pasted text drops the sender's address and the sent time, which are the two facts a dispute turns on.
Give recurring request types a form. Tag the last 100 messages in the shared inbox by request type. Any type that arrives every week gets a structured intake form. In Microsoft 365, a Forms form and a Power Automate flow (When a new response is submitted, then Get response details, then SharePoint Create item) write each request straight into a list, with the response kept as the original (Microsoft's examples). Microsoft 365 business and enterprise plans include cloud flows with standard connectors (licensing FAQ, as of September 2026); confirm each connector in the flow is marked standard.
Parse only fixed-format email. System notifications, such as web shop order confirmations, can be parsed reliably; email written by people can't. The test: if the last 20 messages from that sender all have the same labels in the same order and no person wrote any of them, parse it. Put the From address and subject filter in the Power Automate trigger, not a later condition, because a run the condition rejects still counts against your plan's run quota (Microsoft's email trigger documentation).

3. Typing figures out of documents

What it looks like: supplier invoices, delivery notes, certificates or timesheets arrive as PDFs or scans, and someone types the values in.

The error it produces: transposed digits (1,820 keyed as 1,280 passes every "does this look reasonable" check) and the same document processed twice. Stop duplicates first, because that is the cheapest fix; the rules for catching a second copy keyed slightly differently are in our back-office automation examples.

Measure it with double data entry, a method long used in clinical research data management. A second person keys the same 50 documents into a blank copy of the sheet without seeing the first person's entries, and you compare the two with the formulas in the measurement section. Every difference is at least one error, and the document tells you whose.

Setting an extraction confidence threshold

Extraction tools return a confidence score per field. Microsoft's Document Intelligence documentation says a confidence of 0.95 "indicates that the prediction is likely correct 19 out of 20 times" (accuracy and confidence scores, as of September 2026). The same page notes that not every field returns a score, and that text-reading (OCR) confidence is separate from field confidence, so check both. A confidence score is the model's own estimate, not a measurement on your documents. Back-test it on yours:

Pick 150 documents of one type from the last six months whose keyed values have since been confirmed, such as invoices paid without dispute, including every supplier layout and the worst scans. Anywhere from 100 to 200 works; with fewer, a clean result proves little (see the rule of three below).
Run them through the tool and export one row per field: document (column A), field name (B), extracted value (C), confidence (D), keyed value (E).
In column F, mark each row right or wrong, for example =TRIM(C2)=TRIM(E2), or a tolerance check for amounts. Where they disagree, check the document. Sometimes the keyed value was the wrong one; correct it and count it, because it is another reading of your manual error rate.
Put a candidate threshold in cell H1 and calculate:

Share of field values auto-accepted:
=COUNTIFS(D:D,">="&$H$1)/COUNT(D:D)

Error rate among auto-accepted values:
=COUNTIFS(D:D,">="&$H$1,F:F,FALSE)/COUNTIFS(D:D,">="&$H$1)

These show how many values would skip review at that threshold and how often they were wrong. For one field at a time, add B:B,"Invoice total", as the first criteria pair in each COUNTIFS and replace COUNT(D:D) with COUNTIFS(B:B,"Invoice total").

Try 0.80, 0.85, 0.90 and 0.95. Our rule: for each field, choose the lowest threshold at which auto-accepted values are wrong no more often than your people get them wrong today. Fields where a wrong value sends money to the wrong place, such as bank details, always go to a person. A field that passes an arithmetic cross-check (line items add up to the subtotal, subtotal plus tax equals the total, the PO number exists) has been checked by something other than the model, so it can carry a lower threshold.

Then measure the number your team will feel: the straight-through processing rate, the share of documents where every required field was accepted and every cross-check passed. Count documents rather than multiplying field rates together; low-confidence fields cluster on the same bad scans, so multiplying understates the rate. Keep the 150 documents and rerun them whenever the vendor changes model version or a supplier with a new layout arrives.

4. Maintaining a spreadsheet that sits between two systems

What it looks like: export from one system, adjust in a workbook full of lookup tables, then import or re-key into the other.

The error it produces: values that are wrong without looking wrong. Three Excel behaviors cause it:

A VLOOKUP without a fourth argument does an approximate match. When the exact ID is missing, it returns the value for the next smaller ID instead of an error (Microsoft's VLOOKUP reference).
IFERROR(VLOOKUP(...),0) turns "not found" into a zero that looks like a real value.
An ID stored as text in one export and as a number in the other never matches.

Cheapest removal: make the workbook fail loudly before you replace it. Press Ctrl+F, open Options, set Within to Workbook and Look in to Formulas, and Find All on VLOOKUP(. Every lookup on an ID needs FALSE as its fourth argument, unless it deliberately looks up a band such as a price tier. Search IFERROR( the same way and replace fallbacks of 0 or blank with visible text such as "NOT FOUND". Add a cell comparing the export's row count with the import's. Then load the result through the destination system's import tool instead of re-keying it.

5. Updating the same status in several places

What it looks like: a job is marked complete in the operations system, then in a shared tracker, then in an email to the customer.

The error it produces: the last update in the chain gets skipped or delayed, and it is often the customer-facing one. To measure it, put last month's completion dates next to the dates customers were told. The average gap is your delay; jobs with no message are your error count.

Cheapest removal: let the status change send the message. If the tracker is a SharePoint or Microsoft Lists list, a Power Automate flow on When an item is created or modified can send the email. That trigger fires on every edit, so a flow that only checks "Status is Complete" emails the customer again whenever someone fixes a typo on a finished job. Add a Yes/No column called CustomerNotified, have the flow set it to Yes after sending, and add this trigger condition:

@and(equals(triggerOutputs()?['body/Status/Value'],'Complete'),equals(triggerOutputs()?['body/CustomerNotified'],false))

It starts the flow only when the status is Complete and the customer hasn't been told. Whoever builds your flows pastes it into the trigger's settings; it assumes Status is a Choice column, and the names must match your list's internal column names.

6. Setting up the same customer or supplier in several systems

What it looks like: a new account is created by hand in the CRM, the accounting system and the operations system.

The error it produces: near-duplicates ("Acme Inc" and "ACME, Inc.") and payment terms that differ between systems from the first day. To size it, run the lookup from the 50-record test across two customer lists, matching on the other system's customer number if you store it, or on name if you don't, and count the customers with no match or different terms.

Cheapest removal: create the customer once and carry a stable key into every other system; choosing that key, and what a merge should do, is covered in our guide to CRM integration challenges. If Salesforce is the second system, you can do this without an integration: add a unique External ID field holding the accounting system's customer number, and have the Data Import Wizard match on it, so a re-import updates existing accounts instead of creating new ones.

7. Copying figures into a recurring report

What it looks like: someone opens four systems, reads totals and types them into a slide for the monthly meeting.

The error it produces: figures nobody can trace. When a number is questioned, nobody can say which report it came from, with which filter, pulled when.

Cheapest removal: before automating anything, give every figure a number lineage note. An illustrative example:

Number lineage note: one row per figure in the report
Figure	Source system	Report or view	Filters applied	Pulled	By
Revenue, August	QuickBooks Online	Profit and Loss	Accrual basis, Aug 1 to 31, all classes	Sep 2, 9:40 a.m.	J. Rivera
Open orders	Operations system	Open orders by site	Status not Complete or Cancelled	Sep 2, 9:55 a.m.	J. Rivera

After three months, read the notes. A figure whose source or filter keeps changing has a definition problem, and automating it only speeds up the argument. A figure with the same lineage every month is mechanical, and it is the first to automate. The pulled time also explains why two people report different totals for the same month: one pulled before a late invoice was posted, the other after.

8. Re-entering a correction in every place the original went

What it looks like: an error is found, and someone fixes it in the sales system, the accounting system, the tracker and the spreadsheet.

The error it produces: partial correction. The copy that gets missed is the one used least, so the stale value survives until it turns up somewhere that matters.

Cheapest removal: build a copy map. List every field your team keys more than once and, next to each, every place it ends up. That number is the field's copy count. Until the copies are removed, the map is the checklist for each correction, and the copy count is the multiplier in the cost calculation below, because every error needs one fix per copy. A rule we use: connect the fields with a copy count of three or more first.

Measure your real error rate this week

You need a spreadsheet and someone who can export from both systems. It works as written for examples 1, 5 and 6, and with double data entry for example 3.

Step 1: take a random sample of 50

Export last month's records from both systems into one workbook, one tab each (Sales and Ops below), with the shared ID in column A. Last month is recent enough that people remember the records and old enough for amendments to have happened. In the Sales tab, add a column of =RAND(), paste it back as values (RAND recalculates on every change), sort by it, and copy the first 50 IDs into column A of a new tab called Compare. Records picked by hand are the memorable ones, which are rarely typical.

Step 2: line the two systems up

B2:  =XLOOKUP($A2,Sales!$A:$A,Sales!D:D,"MISSING")
C2:  =XLOOKUP($A2,Ops!$A:$A,Ops!G:G,"MISSING")

These pull the same field (say, the delivery address, in column D of one export and G of the other) for each sampled ID. Fill down to row 51 and repeat in further column pairs for every field keyed into both systems. Without XLOOKUP, use =IFERROR(INDEX(Ops!G:G,MATCH($A2,Ops!$A:$A,0)),"MISSING"). If every row says MISSING, one system exported its IDs as text and the other as numbers; convert one ID column to match the other first.

Step 3: count the mismatches

Records missing from Ops:
=COUNTIF(C2:C51,"MISSING")

Text fields (ignores extra spaces and capitals):
=SUMPRODUCT(--(TRIM(B2:B51)<>TRIM(C2:C51)))

Text fields where capitals matter, such as part codes:
=SUMPRODUCT(1-EXACT(TRIM(B2:B51),TRIM(C2:C51)))

Amounts more than half a cent apart:
=SUMPRODUCT(--(ABS(D2:D51-E2:E51)>0.005))

Dates, ignoring any time of day:
=SUMPRODUCT(--(INT(F2:F51)<>INT(G2:G51)))

Records with at least one mismatch (fill H2 down, then count):
H2:  =OR(TRIM(B2)<>TRIM(C2),ABS(D2-E2)>0.005,INT(F2)<>INT(G2))
=COUNTIF(H2:H51,TRUE)

Each formula counts how many sampled records disagree on one pair of columns. Excel's = and <> ignore capitals, which is why the part-code version uses EXACT. Count the MISSING records first, then move them to another tab: each is an error of its own, and the amount and date formulas return #VALUE! while they stay. If a text column shows mismatches you can't see, the export probably contains non-breaking spaces, which TRIM doesn't remove (Microsoft's TRIM reference); wrap each range as SUBSTITUTE(B2:B51,CHAR(160)," ") inside the TRIM.

Step 4: sort the mismatches before calling them errors

Open the source (the customer's order, the purchase order) for 10 mismatches and put each in one of four piles: a typing error; an amendment that reached only one system; a formatting difference your formulas should ignore (fix the formula and recount); or a source that was itself wrong. The first two piles are your error rate, and the split between them tells you which fix you need, as in example 1.

Step 5: read the result honestly

Fifty records give you a range, not a precise rate. Take r, the share of records with at least one real mismatch, and estimate the 95% margin of error with =1.96*SQRT(r*(1-r)/50). Eight bad records out of 50 is 16%, plus or minus about 10 points, so the true rate is probably between 6% and 26%. The shortcut gets rough below about five bad records. For planning a sample, the widest the margin gets (at a rate of 50%) is:

Largest 95% margin of error by sample size
Records sampled	Margin (percentage points)
50	±14
100	±10
200	±7
400	±5

Two more rules make this usable. First, a clean sample doesn't mean a zero rate. Statisticians call the shortcut the rule of three: with zero errors in n records, the true rate could still be as high as about 3/n at 95% confidence, so a clean sample of 50 still allows up to 6%. Second, you are making a decision, not writing a paper. Run the cost calculation below at both ends of your range; if both ends lead to the same decision, stop, and if not, sample another 50. Use the record-level rate for the range and the field-level count for the cost, because mismatched fields cluster in the same hurried records and counting each field as an independent test makes the range look tighter than it is.

What it actually costs: a worked calculation

Typing time is the cost everyone already knows. The worksheet below adds the three that stay hidden: correction, reconciliation and errors that reach a customer. The inputs are illustrative; replace them with yours.

Monthly cost of re-keying orders between two systems (illustrative inputs)
Line	How it's calculated	Result
Fields keyed per month	800 orders × 10 fields	8,000
Errors per month	8,000 × 1.2% field error rate	96
Minutes per correction	10 to find and confirm + (3 copies × 3 minutes to fix each)	19
Correction hours	96 × 19 ÷ 60	30.4
Reconciliation hours	Logged over one month-end check	12
Keying hours	800 orders × 4 minutes ÷ 60	53.3
Keying cost	53.3 hours × $35 loaded hourly cost	$1,867
Correction and reconciliation cost	(30.4 + 12) hours × $60 loaded hourly cost	$2,544
Failure cost	6 credit notes or reissued invoices traced to keying × $120 each	$720
Total	Sum of the three cost lines	$5,131 a month, about $61,600 a year

Where each input comes from:

Field error rate: mismatched fields ÷ fields compared. Here, 6 mismatches in 500 fields (50 records × 10).
Minutes per correction: time the next five corrections from "someone noticed" to "fixed everywhere", using the copy count from example 8.
Reconciliation hours: have whoever checks one system against the other log one period. Designing that check with control totals is covered in our ERP integration best practices.
Failure cost: read the reason on last quarter's credit notes and reissued invoices, count those a keying error caused, and add reshipping and goodwill credits.
Loaded hourly cost: wage plus employer payroll taxes and benefits, per hour worked, from payroll or your finance lead. Use the rate of whoever does each task; fixing and reconciling often fall to more senior people.
Delay: put each system's created date in spare columns J and K; =SUMPRODUCT(K2:K51-J2:J51)/COUNT(K2:K51) is the average days the second team waits. It stays out of the total, but customers notice it.

Now change one input. Even at 1.2%, fixing and reconciling costs more than the typing. At a 3% field error rate, errors rise to 240 a month, correction to 76 hours and the monthly total to $7,867, before any extra credit notes. Cut the copy count from three to one by connecting two of the systems and each correction falls from 19 minutes to 13, which at 1.2% saves about 10 hours a month. In these numbers, the first money is better spent stopping errors at entry and removing copies than on typing faster.

Data quality practitioners summarize this pattern as the 1-10-100 rule, usually attributed to George Labovitz and Yu Sang Chang (1992): $1 to prevent a bad record at entry, $10 to correct it later, $100 if it is never caught. Treat it as a heuristic. Nobody measured those ratios on your process. The worksheet gives you your own: here, a correction costs about $19 (19 minutes at $60 an hour) and an error that reaches a customer $120. Set those against the per-record cost of prevention, such as a required field, a drop-down list or an import instead of retyping.

Check what you already pay for before commissioning anything

Some re-keying survives only because nobody has had time to read the help pages of software the business already pays for. Before scoping any build, list the three fields your team keys most, check this table, and search your own systems' help for "import", "rules" and "recurring". Details are as of September 2026.

Features that remove re-keying in common business software
Product and feature	What it removes	What to watch
QuickBooks Online bank rules (All apps, Accounting, Rules)	Categorizing bank feed transactions one at a time	The Auto-add setting confirms matching transactions without review. Our default: run a new rule without auto-add for a month first.
QuickBooks Online recurring transactions (All apps, Accounting, Recurring transactions)	Retyping the same bill, invoice or journal entry every period	Scheduled creates the transaction automatically. Reminder prompts someone to edit it first, which suits amounts that vary. Unscheduled is a template used on demand.
Business Central Text-to-Account Mapping (from the Payment Reconciliation Journal)	Posting recurring bank lines, such as bank fees or fuel, by hand	Mapped payments post to the account without being applied to open entries, and a High match confidence from automatic application overrides a mapping.
Salesforce Data Import Wizard	Retyping batches of accounts, contacts, leads, campaign members or custom object records	Up to 50,000 records at a time. Match on a unique External ID field so a re-import updates records instead of duplicating them.
Salesforce Data Loader	Batches too large for the wizard, objects it doesn't support, and scheduled nightly loads	A client application someone installs and runs. Up to 5 million records with Bulk API, 150 million with Bulk API 2.0.
Microsoft Forms with Power Automate	Retyping emailed requests into a list	Standard connectors are included in Microsoft 365 business plans (see example 2). Filter in the trigger, not in a condition.

If one of these covers a field on your list, the fix is configuration, not a project. Rerun the 50-record test afterwards so you know it worked.

If the test shows a real problem and nothing in that table covers it, bring the Compare tab, the names of the two systems and last month's volumes to a conversation. We would start with the fields that have the highest copy count and check whether each system's API lets them be written directly, and we'll say so if a setting you already own would do the job. Our business automation and integration work starts with one workflow like this.