Why your LEDES 98B file gets rejected: spec line, header row, and field counts
Before anything about your invoice's numbers gets checked, a LEDES 98B file has to pass a handful of purely structural tests. This is the layer that decides whether a billing system opens the file at all, and it runs in a specific order: each check below is the next thing that gets looked at once everything before it passes.
1. The spec line
The very first line has to be exactly LEDES1998B[]. Not close, not the right version number with different brackets, exactly that string. If it's missing, misspelled, or the file starts with something else (a blank line that didn't get stripped, a byte-order mark from a particular export tool, anything), parsing stops right there with nothing else checked. This is the single most common reason a file fails immediately: something upstream added a stray character before the spec line, invisibly.
2. Line terminators
Every line in a LEDES 98B file, including the spec line and the header, ends with []. If a line doesn't, that's flagged with the exact line. This one is deceptively easy to break with a text editor: a manual edit to fix something else can accidentally strip the trailing [] off the line you touched, and now that specific line fails even though visually nothing looks wrong.
3. The header row
Right after the spec line, the header row has to list every field name, pipe-delimited, in the exact order the spec defines, matched exactly. LEDES 98B has 24 fields (INVOICE_DATE through CLIENT_MATTER_ID). If even one is missing, renamed, or out of order, the whole header fails, and the error tells you what was expected versus what was found so you can diff it directly against your own file.
4. Field count per row
Once the header passes, every data row has to have exactly as many pipe-delimited values as the header has field names. Not the right values yet, just the right count. This is usually where a genuinely malformed row shows up: a description field that contains an unescaped pipe character splits into two values instead of one, throwing off the count for that row (and only that row; the check runs independently per line).
Why this order matters for debugging
Because parsing stops at the first structural failure in the spec line, header, or missing-header cases, a broken spec line will never show you a header problem too, even if one also exists. Fix them one at a time, top to bottom, rather than assuming the first error reported is the only thing wrong. Field-count and terminator problems are the exception: those are collected per row across the whole file, so a report showing five different bad rows is telling you about five separate rows, not one repeated failure.
Try it
This whole layer is Tier 1: free (your first file needs no signup), full report every time, not paywalled to see the exact line and field. If you're not sure whether a specific issue is structural (this guide) or a data-format problem within an otherwise well-formed row (dates, money, codes), the date and currency formatting guide covers that next layer down.