LEDES 98B vs. 98BI vs. XML 2.0.4 vs. XML 2.1: which one does your billing system actually want
You don't usually pick a LEDES format. A client's e-billing platform tells you which one it wants, and the actual difference between what you were producing before and what it's now asking for is often unclear from the acronym alone. Here's what each one actually is.
LEDES 98B
The baseline. Spec line LEDES1998B, pipe-delimited, 24 fields covering invoice totals, line items, and basic timekeeper info. Dates are YYYYMMDD. No currency field at all (one invoice, one implied currency, no way to state which). No tax fields, no address fields for either party. If your billing system's request just says "LEDES" with no other qualifier, this is usually what's meant, since it's the format almost every other LEDES variant treats as its baseline.
LEDES 98BI
98B plus 28 more fields, same pipe-delimited shape, different spec line (LEDES98BI V2, not LEDES1998B). The "I" is for International, and the added fields are exactly what that implies: INVOICE_CURRENCY (a real ISO-4217 code, since more than one currency is now possible across invoices), full law-firm and client address blocks, PO_NUMBER and CLIENT_TAX_ID, timekeeper name split into first/last instead of one field, and a tax block (LINE_ITEM_TAX_RATE, LINE_ITEM_TAX_TOTAL, INVOICE_TAX_TOTAL, INVOICE_TAX_CURRENCY). If your client operates across borders, or the request specifically mentions tax or currency handling, this is the one being asked for, not plain 98B.
LEDES XML 2.0.4
The same data, structured as XML instead of pipe-delimited rows. Every field that has a direct 98B/98BI equivalent (an invoice number, a line item total) maps onto that same canonical concept, so if you already understand 98BI's fields, you already understand most of what 2.0.4 asks for, just nested instead of flat. Dates are still YYYYMMDD. The practical reason a billing system prefers XML over a flat format is usually structural validation on their end (an XML schema catches shape problems a pipe-delimited parser has to check by hand) rather than any new billing concept the format itself introduces.
LEDES XML 2.1
The newest format, and the one with real, substantive differences from the other three, not just a structural change. Dates switch to ISO 8601 (2026-04-16, not 20260416). Required fields become soft: a missing one is reported as an issue rather than rejecting the file outright, which is a genuinely different validation philosophy than every format before it (98B and 2.0.4 both fail hard on a missing required value). Closed-set fields (timekeeper level, matter billing type, discount/credit codes) become real enumerations instead of free text. Tax handling gets substantially richer (tax-on-tax, increase/decrease flags, country-plus-locality jurisdiction instead of one field), and several invoice-level concepts (bill-to and payable-by parties, credit notes, regulatory statements) exist for the first time. This is covered in more depth in what LEDES XML 2.1 checks that 98B can't.
The practical answer
If a billing system's onboarding docs name a spec explicitly, that's the one to build against, since the four aren't interchangeable and a file in the wrong one will bounce regardless of how correct its data is. If you're not sure which one you're being asked for, the presence of a currency or tax field in what you've been shown is 98BI, not plain 98B; XML wrapping around otherwise-familiar field names is 2.0.4 or 2.1; ISO-format dates specifically mean 2.1.
Try it
BriefCheck checks all four: LEDES98B, LEDES98BI, LEDESXML204, and LEDESXML21, each with its own sample file to try against. Free tier, Tier 1 structure checks, and your first file needs no signup.