LEDES Billing Format: Why Law Firm Invoices Get Rejected

A law firm sends a perfectly correct invoice: the hours are right, the rate is right, the narrative is honest, the client agreed to every dollar on it. The client's e-billing system rejects it anyway, not because anything about the legal work is wrong, but because line 14 of the file has 23 pipe-delimited fields instead of 24. Nobody misspelled anything. A comma-separated export tool dropped one blank field at the end of a row, and a format built in 1998 has no tolerance for that. This happens constantly in legal billing, and it is the reason the phrase "ledes billing format" shows up in support tickets more often than in marketing copy. Firms that process high volumes of legal invoices, or build document intelligence into their legal document workflows, eventually have to understand LEDES at the field level, not the marketing-page level, because that is the level where files actually fail.

LEDES is a family of formats, not one file type

LEDES stands for Legal Electronic Data Exchange Standard, and it did not start as a legal-industry committee project. It began in 1995 as an initiative coordinated by Price Waterhouse (before the PwC merger), building a common file format so corporate legal departments could pull invoice data out of law firm billing systems without a human retyping every line. The organization that maintains it today, the LEDES Oversight Committee, incorporated as a California nonprofit in 2001 and still governs the spec through a small board.

Since then the standard has split into two lineages that solve different problems. The flat-file lineage (LEDES 1998B, and its expense-heavy sibling LEDES 1998BI) is a plain ASCII text file, pipe-delimited, one line per invoice header or line item. The XML lineage (LEDES XML 2000, then XML 2.0, then 2.1, then 2.2) is a hierarchical, schema-validated format built for richer data: multi-currency invoices, tax handling, credit notes, and international billing that the flat file was never designed to carry. Each XML revision added structure. XML 2.0, released in 2006, defined 15 segments and 156 data elements. XML 2.1, in 2008, expanded that to 16 segments and 194 elements to support withholding tax and credit notes. XML 2.2, ratified in 2020, reached 18 segments and 206 elements, adding tiered tax support for jurisdictions where a single flat tax rate does not apply. Despite all that, LEDES 1998B remains the format most US law firms and e-billing platforms actually exchange day to day, because it is simple enough that almost every practice management system can export it, and most corporate legal departments still accept it as the baseline.

Inside a LEDES 1998B file: the 24 fields in exact order

This is the part almost nothing written about LEDES actually shows: what the 24 fields are, in the order the spec defines them. A LEDES 1998B file opens with a literal header line, LEDES1998B[], followed by the field names in brackets separated by pipes, and every subsequent line is data in that same field order, separated by pipes. Get the count or the order wrong on any line and a compliant parser rejects the whole file, not just the bad line, because the header line is the contract for every row that follows.

#	Field name	What it carries
1	INVOICE_DATE	Date the invoice was issued
2	INVOICE_NUMBER	Law firm's unique invoice identifier
3	CLIENT_ID	Corporate client's ID for the billing party
4	LAW_FIRM_MATTER_ID	The matter number as the firm tracks it
5	INVOICE_TOTAL	Sum of all line items on the invoice
6	BILLING_START_DATE	First date of the billing period
7	BILLING_END_DATE	Last date of the billing period
8	INVOICE_DESCRIPTION	Free-text summary of the invoice
9	LINE_ITEM_NUMBER	Sequential line number within the invoice
10	EXP/FEE/INV_ADJ_TYPE	Whether the line is a fee, expense, or adjustment
11	LINE_ITEM_NUMBER_OF_UNITS	Hours (fees) or quantity (expenses)
12	LINE_ITEM_ADJUSTMENT_AMOUNT	Any write-down or write-up applied to the line
13	LINE_ITEM_TOTAL	Billed amount for the line, after adjustment
14	LINE_ITEM_DATE	Date the work or expense occurred
15	LINE_ITEM_TASK_CODE	UTBMS task code (e.g. L110)
16	LINE_ITEM_EXPENSE_CODE	UTBMS expense code (e.g. E106), blank on fee lines
17	LINE_ITEM_ACTIVITY_CODE	UTBMS activity code (e.g. A102), blank on expense lines
18	TIMEKEEPER_ID	Law firm's internal ID for the person who did the work
19	LINE_ITEM_DESCRIPTION	The narrative explaining what was done
20	LAW_FIRM_ID	The firm's identifier in the client's system
21	LINE_ITEM_UNIT_COST	Hourly rate (fees) or unit price (expenses)
22	TIMEKEEPER_NAME	Name of the timekeeper
23	TIMEKEEPER_CLASSIFICATION	Role, e.g. Partner, Associate, Paralegal
24	CLIENT_MATTER_ID	The matter number as the client's own system tracks it

Notice how much of a single invoice line is actually about identity matching rather than the work itself: fields 3, 4, 18, 20, and 24 all exist to reconcile the law firm's internal IDs against the client's internal IDs. That reconciliation, not the narrative text, is where a large share of real rejections originate, because LAW_FIRM_MATTER_ID and CLIENT_MATTER_ID have to match values the client's e-billing system already has on file, exactly, including case sensitivity in some platforms.

What UTBMS task and activity codes actually encode

UTBMS, the Uniform Task-Based Management System, is the coding layer that rides inside fields 15 through 17. It was developed jointly by the American Bar Association's Section of Litigation and the Association of Corporate Counsel (then the American Corporate Counsel Association), with Price Waterhouse coordinating the original effort, so that legal spend could be compared across firms doing the same category of work. In April 2006 a separate UTBMS Update Initiative merged into the LEDES Oversight Committee, which now maintains the full code set as the single reference at utbms.com. The codes are not one flat list. They are organized into separate code sets for different practice areas, and a line item's task code has to come from the set that actually matches the matter type.

Code set	Practice area	Range
L100-L500	Litigation: case assessment, pre-trial, discovery, trial prep, appeal	Core litigation phases
L600-L690	eDiscovery (identification, collection, review, production)	Ratified in 2011
B100-B400	Bankruptcy: administration, operations, claims/plan, advice	Bankruptcy matters
C100-C400	Counseling: fact gathering, research, analysis, communication	Advisory/non-litigation
P100-P800	Project: administration through maintenance tasks	Corporate/project work
PA100-PA700	Patent prosecution, domestic and international	IP: patent
TR100-TR799	Trademark prosecution and maintenance	IP: trademark

Activity codes describe the action taken, independent of subject matter, so the same activity code set applies across all the task code sets above. The core activity codes are A101 (plan and prepare for), A102 (research), A103 (draft/revise), A104 (review/analyze), A105 (communicate, in firm), A106 (communicate, with client), A107 (communicate, with other outside counsel), A108 (communicate, other external), and A109 (appear for/attend), with additional codes covering more specialized functions like document review culling and quality control on larger e-discovery matters. Expense codes follow the same pattern in field 16: E101 is copying, E106 is online research, E110 is out-of-town travel, E112 is court fees, E119 is experts, and the range runs up through E131 for late fees, with a few IP-specific codes (E125-E131) added later for patent and trademark filing costs like drawings and official fees. A single fee line item needs exactly one task code and one activity code from a set that matches the matter type. An expense line needs an expense code and leaves the activity code blank. Get the wrong set (using a litigation L-code on a bankruptcy matter) and the file can be perfectly well-formed and still fail a client's coding rules.

A worked example: building one valid LEDES 1998B line and checking the math

Take a single fee entry: an associate spent 2.5 hours researching case precedent. Task code L110 (fact investigation and development, under the L100 case-assessment series), activity code A102 (research), rate $450 per hour. The line item total field is not free text, it is a computed value the parser checks: LINE_ITEM_NUMBER_OF_UNITS multiplied by LINE_ITEM_UNIT_COST, adjusted by LINE_ITEM_ADJUSTMENT_AMOUNT, has to equal LINE_ITEM_TOTAL exactly. Here, 2.5 times $450.00 is $1,125.00, so if the adjustment amount is 0.00, LINE_ITEM_TOTAL must read exactly 1125.00. If the firm's billing software rounds hours to two decimal places internally but the LEDES export truncates to one decimal, the computed total can come out a cent or two off from what a strict validator recomputes, and that mismatch alone is a common, entirely avoidable rejection.

The same check runs one level up. INVOICE_TOTAL (field 5) has to equal the sum of every LINE_ITEM_TOTAL on the invoice. On an invoice with 40 line items, if one line is accidentally coded as an adjustment type instead of a fee type, it can get excluded from the client system's line-item sum while still being counted in the firm's own INVOICE_TOTAL calculation, producing a total that is off by exactly that one line's value. That kind of mismatch is trivial to spot once you know to recompute both sums independently and compare them, which is exactly what a validation pipeline has to do before a file ever reaches a human reviewer.

Why law firm invoices actually get rejected

Rejections split into three layers, and they get progressively harder to catch. The first layer is file structure: the header line has to be the literal string LEDES1998B[] with the field names in brackets, every data row needs exactly 24 pipe-delimited values in the defined order, and dates need to parse in the format the receiving system expects. A dropped field, an extra pipe inside a narrative that was not escaped, or a header that does not match the field list exactly will bounce the file before anyone even looks at the content. This layer is almost entirely mechanical and is the easiest to automate away.

The second layer is code validity. The task code has to exist in the code set that matches the matter type, the activity code has to be a real UTBMS code, and increasingly, the specific task-activity combination has to be one the client's outside counsel guidelines actually permit. Some corporate legal departments explicitly block certain codes, for example refusing to pay for A105 (communicate, in firm) above a capped percentage of total hours, on the theory that internal law-firm coordination time should not be billed to the client at full rate. A file can be structurally perfect and still fail here because the codes are valid UTBMS codes, just not codes this particular client will pay for.

The third layer is referential and business-rule validation, and it is the layer human reviewers still catch things a parser cannot. CLIENT_ID, LAW_FIRM_MATTER_ID, and CLIENT_MATTER_ID all have to match records the receiving e-billing platform already has on file for that matter, which means a new associate added to a matter without their TIMEKEEPER_ID being pre-approved in the client's system will cause every line that timekeeper touched to reject, even though nothing about the invoice format is wrong. This is also where rate validation lives: TIMEKEEPER_CLASSIFICATION and LINE_ITEM_UNIT_COST get checked against the rate the client agreed to for that classification, and a rate that drifted above the approved cap, even by a dollar, fails here.

Block billing and narrative rules: the layer nobody's parser catches

One rejection reason is worth calling out separately because it lives entirely in field 19, LINE_ITEM_DESCRIPTION, and no amount of structural validation will find it. Block billing is when a single line item's narrative describes several distinct activities compressed into one time entry and one number of hours, for example "Reviewed discovery documents, drafted motion to compel, and communicated with client regarding strategy, 4.5 hours" tagged under one task and activity code. The problem is not that the format is wrong. Every field parses fine. The problem is that the narrative describes review work (A104), drafting work (A103), and client communication (A106) as if they were one activity, which makes it impossible for the client to see how much of that 4.5 hours went to each. Most outside counsel guidelines explicitly prohibit block billing and require each distinct activity to get its own line item with its own accurate code, and e-billing platforms increasingly run narrative text through pattern checks looking for multiple activity verbs, vague phrases like "various" or "miscellaneous," or narratives under a minimum character length, flagging entries for manual audit even when the file itself is fully valid LEDES.

LEDES 1998B versus LEDES XML: when the flat file breaks down

The flat file works well until an invoice needs to carry information the 24-field structure was never built for. A few concrete limits: LEDES 1998B has no native field for tax on legal fees, which matters for firms billing clients in jurisdictions with VAT or GST on professional services. It also repeats invoice-level fields (INVOICE_DATE, INVOICE_TOTAL, CLIENT_ID, and others) on every single line item row, which is redundant but was a deliberate simplicity tradeoff so each line could be parsed independently. LEDES XML fixes both, at the cost of needing a schema-aware parser instead of a simple split-on-pipe read.

Format	Structure	Tax support	Best fit
LEDES 1998B	Flat, pipe-delimited, 24 fields	None	Domestic US fee and expense billing
LEDES 1998BI	Flat, expanded expense detail	Limited	Firms with heavy itemized expenses
LEDES XML 2.1	16 segments, 194 elements	Withholding tax, credit notes	Cross-border billing
LEDES XML 2.2	18 segments, 206 elements	Tiered tax	Multi-jurisdiction, complex tax regimes

In practice, most firms only move to XML when a specific client's e-billing platform requires it, because the flat file remains cheaper to generate from standard practice management exports. For a broader look at how legal documents get processed beyond billing, our contract OCR guide covers the extraction side of legal document intelligence, since a firm's billing narratives and its underlying contracts are often processed by related tooling.

What a real LEDES processing pipeline has to enforce

Building or evaluating a LEDES processing pipeline means implementing checks at each of the three layers described above, in order, because later checks are wasted effort if earlier ones fail.

1. Structural parse: verify the header line matches LEDES1998B[] with the exact 24 field names, confirm every data row has 24 pipe-delimited values, and reject (with a specific line number) any row that does not.
2. Type and format checks: dates parse correctly, numeric fields (units, unit cost, totals, adjustment amount) are actually numeric, and TIMEKEEPER_CLASSIFICATION matches an allowed value set.
3. Math validation: recompute LINE_ITEM_TOTAL from units, unit cost, and adjustment for every line, recompute INVOICE_TOTAL as the sum of all line totals, and flag any mismatch beyond a defined rounding tolerance.
4. Code validity: confirm each task code belongs to the code set appropriate for the matter type, each activity code is a real UTBMS code, expense lines carry an expense code and blank activity code, and fee lines carry activity and task codes with blank expense code.
5. Referential match: confirm CLIENT_ID, LAW_FIRM_MATTER_ID, CLIENT_MATTER_ID, LAW_FIRM_ID, and TIMEKEEPER_ID against records already on file for that matter, since these are the fields most often stale after staffing changes.
6. Guideline and narrative rules: apply the client's specific outside counsel guidelines, rate caps by classification, blocked or capped task-activity combinations, minimum narrative length, and block-billing pattern detection.

Each of those six steps produces a specific, actionable rejection reason rather than a generic "invalid file" message, which is the difference between a pipeline a billing team can actually use and one that just adds another opaque failure point between the firm and getting paid.

Where OCR and document intelligence fit into LEDES processing

Not every invoice a corporate legal department receives arrives as clean LEDES data. Smaller firms, solo practitioners, and firms using older practice management systems still send PDF invoices, sometimes scanned, sometimes generated straight from a word processor with no export capability at all. Getting that invoice into valid LEDES 1998B or XML means first extracting the same structured data the LEDES fields expect (timekeeper names, dates, hours, rates, narratives, and, if the firm coded it internally, task and activity codes) out of an unstructured document layout that varies firm to firm. That extraction step is document OCR and layout parsing, not billing logic, and it has to run before any of the validation described above is even possible. A document intelligence pipeline built for legal invoices has to combine layout-aware OCR to read the source document with a mapping layer that places extracted values into the correct LEDES fields and, where the source invoice never had UTBMS codes at all, a classification step that assigns them based on the narrative text. Getting that mapping right up front avoids exactly the kind of field-count and math mismatches described earlier, since a pipeline that extracts LINE_ITEM_NUMBER_OF_UNITS and LINE_ITEM_UNIT_COST directly from the source document, rather than having a person retype them, cannot introduce the rounding drift that causes so many LINE_ITEM_TOTAL mismatches in practice, the same line-item math validation problem covered from the vendor-invoice side in our invoice line item OCR guide. Written by Nupura Ughade.