LEDES date, money, and code formatting errors, fixed
This is the layer below the structural checks: the spec line, header, and row shape all passed, and now individual field values are getting checked against what each one is actually allowed to look like. Three categories cover almost everything.
Dates
Every date field (INVOICE_DATE, BILLING_START_DATE, BILLING_END_DATE, LINE_ITEM_DATE) has to be exactly eight digits, YYYYMMDD, no dashes, no slashes. 19990115 is January 15, 1999. 1999-01-15 or 01/15/1999 both fail immediately, before the date is even checked for validity, because they don't match the expected shape at all.
There's a second, separate failure mode once the shape is right: the eight digits have to form a real calendar date. 19990230 is eight digits in the right shape and still gets rejected, because February 30th doesn't exist. If your error is about the format itself, check for separators or a swapped month/day. If it's about the date being invalid despite looking like the right shape, check for an actual impossible date, most often from a month/day transposition (US-style MM/DD data exported into a DD/MM slot, or the reverse).
Money
Line-item and invoice amounts (LINE_ITEM_TOTAL, LINE_ITEM_UNIT_COST, INVOICE_TOTAL, and others) have to be plain decimal numbers: digits, an optional decimal point, up to four decimal places. No currency symbols, no thousands separators. 1500.00 is fine. $1,500.00 is not, and it fails on the comma and the dollar sign both, not just one of them. This is the single most common field-format rejection, because spreadsheet software formats currency with a symbol and thousands separators by default, and an export that doesn't explicitly strip that formatting carries it straight into the file.
A couple of amount fields (LINE_ITEM_TOTAL, LINE_ITEM_ADJUSTMENT_AMOUNT) allow a leading + or -, since adjustments and credits are legitimately negative. Most others don't allow a sign at all, so a negative value in a field that isn't supposed to carry one is its own separate failure, distinct from the comma/symbol problem above.
Codes
A handful of fields are constrained to a closed set of values, not free text. EXP/FEE/INV_ADJ_TYPE only accepts E, F, IF, or IE (case-insensitive, normalized to uppercase on the way in) — expense, fee, or one of two adjustment types. Task codes, expense codes, and activity codes accept alphanumeric characters plus limited punctuation, but not arbitrary text. If one of these fields is rejected, it's almost always because the actual billing category or task code from your system doesn't map to the value LEDES expects, which is a mapping-table problem in the export, not a typo to fix by hand.
Currency, 98BI only
Plain LEDES 98B has no currency field at all; it assumes one implied currency for the whole invoice. 98BI adds INVOICE_CURRENCY, and it has to be a real ISO-4217 three-letter code (USD, EUR, GBP, and around 140 others) — not a symbol, not a country name, not a made-up abbreviation. If you're seeing this rejection on a plain 98B file, check that you're not accidentally including a field that spec doesn't have; if you're on 98BI, check the exact three-letter code against the ISO-4217 list rather than assuming a common one is obviously right (Swiss franc is CHF, not SFR or CH, for instance).
Try it
All of this is Tier 1: free and complete, and your first file needs no signup. The report gives you the line, the field, and the actual offending value for every one of these, so you're comparing your file against the rule directly rather than guessing.