What LEDES XML 2.1 checks that 98B and XML 2.0.4 can't
XML 2.0.4 is mostly a structural change over 98B and 98BI: the same billing concepts, nested in XML instead of pipe-delimited. XML 2.1 is a different thing. It changes what "valid" means for a required field, adds real enumerated code lists where earlier formats accepted whatever text you typed, and models tax and invoice-level relationships that don't exist in any earlier format at all.
Dates move to ISO 8601
Every earlier LEDES format, flat or XML, uses YYYYMMDD. 2.1 switches to xsd:date: 2026-04-16, dashes included. If you're adapting an export that already produces 2.0.4, this is the first thing that will break, since the date logic almost certainly hardcodes the old eight-digit format.
Missing a required field doesn't reject the file
This is the real philosophical change. In 98B, 98BI, and XML 2.0.4, a required field that's missing or empty is a hard failure: the row (or, in the flat formats, sometimes the whole file) gets rejected. XML 2.1's schema-declared required fields (minOccurs) are checked, but a violation is reported as an issue, not treated as fatal. Parsing continues, and you get a complete report of everything wrong with the file in one pass, rather than stopping at the first missing field and only learning about the second one on your next attempt. The LOC's own naming for this is the Notification pattern.
Enumerations are real, not free text
98B and 98BI accept task codes and timekeeper classifications as loosely-patterned text; what's actually in that field is a mapping-table matter between your billing system and the client's. 2.1 defines actual closed code lists in the schema for several fields that used to be open: tk_level (50 defined codes), matter_billing_type, the discount/credit type and category codes, and increase/decrease indicators. A value outside the defined list fails validation the same way any other format-mismatch does, but now there's a specific, checkable list behind it instead of "whatever the client's system happens to accept."
Tax gets a real model
Earlier LEDES formats that handle tax at all (98BI, 2.0.4) treat it as a rate and a total, roughly. 2.1 adds tax_on_tax and increase_decrease handling, and splits what used to be one jurisdiction concept into country and locality separately. If your billing relationship involves tax-on-tax (VAT calculated on top of another tax, common in some jurisdictions) or sub-national tax jurisdictions, 2.1 is the first LEDES format that can actually represent it rather than forcing it into a single rate field.
New invoice-level concepts
A handful of things exist in 2.1 that no earlier format has a place for at all: separate bill-to and payable-by parties (useful when whoever receives the invoice isn't the entity actually paying it), credit notes as their own concept, an invoice reference block, and regulatory statement segments. None of these have a 98B/98BI equivalent to map onto, since the earlier formats simply didn't anticipate the relationship.
A note on where this comes from
The LEDES Oversight Committee hasn't published official 2.1 sample files as of this writing. BriefCheck's 2.1 sample was built directly against the LOC's own authoritative schema (Ledes21.xsd), field by field, rather than adapted from an official example that doesn't exist yet — worth knowing if you're comparing our sample against anyone else's and finding they don't match exactly.
Try it
BriefCheck's Tier 1 structure check covers XML 2.1 the same as the other three formats: free, complete report, and your first file needs no signup. The XML 2.1 sample file is available from the same sample picker as the other three specs.