Tables and lists give readers a visual shortcut. They strip out the connective tissue of prose and arrange information so the eye can scan it fast. That's the point. But that same structure creates a proofreading blind spot: because the layout looks organised, the brain reads it as correct. A number transposed in a table, a missing row, a bullet that breaks the parallel structure of the five before it. These errors sit in plain sight and get missed precisely because everything around them looks tidy.
Proofreading structured content requires a different method than proofreading prose. You're not reading for flow. You're checking for internal consistency, completeness, and accuracy, three things that prose paragraphs don't demand in quite the same way.
Why tables and lists are harder to proofread than paragraphs
When you read a paragraph, your brain processes the sentence sequentially and flags anything that feels grammatically wrong. Tables don't work that way. Readers scan them in two directions at once: across rows and down columns. That two-axis reading means errors in one cell can be masked by correct content in the cells surrounding it.
Lists carry a different trap. A well-written list has parallel structure: every item starts with the same grammatical form, uses a consistent level of detail, and ends with or without punctuation in the same way throughout. Most writers know this rule in principle. In practice, they write the first four items in one session, add three more later, and never reread the whole thing as a unit. The result is a list where items 1 through 4 begin with a verb in imperative form ("Review the draft", "Submit the form") and items 5 through 7 begin with nouns ("Approval process", "Final sign-off").
It doesn't look catastrophically wrong. It just looks slightly off, which is almost worse.
A method for proofreading tables
Check tables in four passes. Don't try to catch everything in one read.
Pass 1: structure. Count the rows and columns. Confirm the header row exists and that every column has a label. Check that no cell is blank when it should contain data. If the table was generated from a data export or copied from a spreadsheet, merged cells and hidden rows are common sources of silent errors.
Pass 2: column consistency. Read straight down each column and ignore the other columns entirely. Every cell in a currency column should contain a currency value. Every cell in a date column should use the same date format. If you're working with an international audience, pay particular attention here: date and number formats differ significantly across countries, and a table that mixes 03/04/2026 with 4 March 2026 will confuse readers even if every individual value is correct.
Pass 3: row logic. Now read across each row. Ask whether the cells in that row are consistent with each other. If row 4 describes a cost category, do its figures add up? If row 7 is a total, does it equal the sum of the rows above it? Arithmetic errors in summary rows are among the most damaging mistakes in business documents, and they're invisible to spell-check.
Pass 4: headings and captions. Read the table title, any column headers, and any footnotes as standalone text. Check that the title actually describes what the table contains. Check that footnotes referenced in the table body (typically with a superscript number or asterisk) have a corresponding note below the table. This is the most commonly skipped step in table proofreading.
If the table contains numerical data, the separate post on proofreading numbers and data in business documents covers the verification steps in more depth.
A method for proofreading lists
Lists need three specific checks that prose paragraphs don't.
Parallel structure. Read the first word of every item in the list. They should all be the same part of speech. Verbs, nouns, adjectives. Not a mix. If you're writing a list of actions, every item starts with a verb. If you're listing features, every item starts with a noun or adjective. Reading just the first word of each item, one after another, is a fast way to catch the mismatch that you'd miss reading the list normally.
Punctuation consistency. Decide upfront whether your list items end with a full stop, a semicolon, or nothing. Then apply that choice to every item without exception. The last item in a list is where inconsistency hides most often, particularly if someone added it after the rest of the list was drafted.
Numbering and order. If you're using a numbered list, the numbers need to be consecutive, and the order of items needs to match any references to the list in the surrounding text. A document that says "complete steps 1 through 5 before submitting" and then presents a five-item list is coherent. One that presents six items is not, even if the error is obvious once you look for it.
The question of when to use numbered lists versus bullet points matters too: numbered lists imply sequence or rank, so if your items have no meaningful order, a numbered list creates a false impression and may draw the wrong questions from readers.
Common errors that survive a first read
Four errors show up consistently in structured content, across industries and document types.
- Orphaned items. A list where one item is clearly a sub-point but is formatted as a top-level bullet. The indentation gets lost during copy-paste or reformatting.
- Duplicate rows. Tables copied from spreadsheets often carry duplicate rows from a filter that wasn't cleared. If the table has a "total" row, a duplicate row inflates it without changing the layout visually.
- Stale data in a carried-forward table. A table copied from an earlier version of the document where one cell was updated and the rest weren't. The dates or figures in the surrounding text no longer match the table.
- Inconsistent units. A cost column where some values are in thousands and some are in full figures, with no label to distinguish them.
Each of these errors is easy to spot once you know to look. None of them will be flagged by a grammar checker or a spell-checker.
Tools and workarounds
Standard grammar tools don't parse table cells or list items as discrete units. Grammarly, for example, may flag a sentence fragment inside a table cell as an error when it's intentionally a short label. Treat automated suggestions inside structured content with more scepticism than you would in a paragraph.
The most reliable approach is to temporarily break the structure. Copy a table column into a blank document as a plain list and read it there, away from the visual noise of the full table. Do the same for list items: paste them into a single paragraph with commas between them and read that paragraph aloud. Errors in register, repetition, and parallelism become audible when the layout isn't helping your brain skip over them.
Reading aloud is underused for structured content. Writers tend to save it for prose. But a list read aloud as a sequence of items, one after another, reveals tonal inconsistencies and awkward phrasing that silent reading misses every time.
Structured content earns trust from readers precisely because it looks authoritative. A table with a column of figures signals precision. A numbered list signals completeness. When errors survive in that content, they undermine the document's credibility more than a typo in a paragraph would, because the form itself made a promise the content didn't keep.