LEDES error code meaning: 2 parts, field and error number

What LEDES files are

LEDES is a family of formats for legal invoices. Corporate clients often ask outside firms to send their bills in one of these formats so that the client's accounts-payable system can read the details automatically, without someone retyping them. The format you use matters, because each one is laid out differently.

TimeSolv's billing guide describes the two main styles clearly. In its words, "LEDES 1998B is a flat, text-based file that follows a strict column/line structure, while LEDES XML uses a tagged format that can carry more structured detail." ( TimeSolv, LEDES Billing Guide for Lawyers)

In practice, a flat text file is read by position. Each value sits in a set column on a set line, so a value that lands in the wrong column can be rejected even if it looks correct to a person. An XML file is read by tags. Each value is wrapped in a label that says what it is, so the system can find it by name. Both styles carry the same kind of information, but they describe it differently. Keep that difference in mind, because it explains why the same problem can have different names in different files.

Why invoices get rejected

TimeSolv's guide makes a point worth remembering before you open any error message: "Most rejections come down to missing required fields, inconsistent coding, or line items that don't match a client's billing rules." ( TimeSolv, LEDES Billing Guide for Lawyers)

Those three causes cover most of what you will see. A missing required field means the file left out a value the client's system must have. Inconsistent coding means the same kind of work was labeled in different ways across lines, so the system cannot match them up. A line item that does not match the client's billing rules is valid as a bill but breaks a condition the client set, such as how work may be described or grouped.

None of these causes is a mystery once you know which field is involved. That is why the error code matters. It turns a vague "file rejected" into a specific field and a specific error.

Read the code in two parts

Here is the example from the LEDES Oversight Committee's error code page. Clients add the code to the end of the error message. Instead of "Bulk Billing not allowed," the message reads "Bulk billing not allowed [1012-0053]." The page explains the parts this way: "The code references the specific field [1012, the time entry description] and the error [53, bulk billing], and the Error Code document identifies what specifically to fix." ( LEDES Oversight Committee, LEDES Error Codes)

So the code has two halves:

• The first part is the field. In the example, 1012 points to the time entry description. This is the place in the invoice where the problem sits.
• The second part is the error. In the example, 0053 points to bulk billing. This is the kind of problem the system found in that field.

The first part answers "where?" and the second part answers "what?" Together they tell you what to look at. The message text, "Bulk billing not allowed," is a plain-language version of the same information. Use the code anyway. The code is what lines up with the reference document, so it is the reliable way to match what you see with what the guide says.

Write the error number exactly as the message shows it, including leading zeros. A similar-looking number can refer to a different error. If your message has a code in a different shape from the example, read it the same way: the field comes first, the error comes second, and the reference document settles the rest.

Find the field in the reference document

The page describes the goal this way: "These Error Codes are a new type of LEDES standard established to provide a standardized structure to ebilling validation errors, intending to standardize the identification of LEDES file submission errors from system-to-system and client-to-client." ( LEDES Oversight Committee, LEDES Error Codes)

That purpose matters for you. Because the codes are meant to mean the same thing from one client to another, you can use the same reference whether the rejection came from a large corporate system or a smaller one. You learn one structure and apply it each time.

The reference is organized as a worksheet, so understand its layout before you search. The page gives a breakdown by file type, with separate columns for XML 2.2x (D), XML 2.1x (E), XML 2.0x (F), and columns G (98BI) and H (98B). ( LEDES Oversight Committee, LEDES Error Codes) The same field may appear more than once, and the entries can differ from one column to the next.

This layout is why the file type matters. The page gives a clear example. Two rows on the V2 Error Codes worksheet both describe the same field, "@FIRM.lf_vendor_id (in XML) and LAW_FIRM_ID (in ASCII)." ( LEDES Oversight Committee, LEDES Error Codes) The information is the same, but it has one name in an XML file and another in an ASCII file. If you read the wrong row, you will look for a name that does not appear in your file and assume the code is wrong.

Confirm your file format first

Before you match a code to a row, confirm which format you actually sent. Do not assume. Many small firms use billing tools that export in a format someone chose once and forgot. Check the file itself. An XML file is tagged. A flat file has columns and lines. If you are unsure, look at the file name, its header, and the export settings in your billing software.

In the rows the example shows, color marks the format: black for XML and blue for ASCII. ( LEDES Oversight Committee, LEDES Error Codes)

The page also shows which columns do not apply to a given format. ( LEDES Oversight Committee, LEDES Error Codes) If your file is XML, skip the ASCII columns. If your file is an ASCII format, skip the XML rows. Reading the right row is most of the work.

A simple habit avoids most mistakes. Write your file format at the top of your notes before you open the worksheet. Then ask whether each row you look up belongs to that format. It takes a moment, and it stops you from spending time fixing a field that was never the problem.

Work through a rejected file step by step

When a file is rejected, it is tempting to open it, scan for something that looks wrong, and start changing values. Resist that. A structured approach saves time and avoids new errors.

1. Copy the full error message. Include the bracketed code. Do not retype it from memory, because one wrong digit can send you to the wrong field. If the client sent several rejections, copy each one separately.

2. Split the code at the hyphen. Write the field number and the error number on separate lines in your notes, with the digits exactly as they appear. In the example, 1012 and 0053 point to different things, and swapping them would send you the wrong way.

3. Confirm the file format. Write down whether you sent XML or a flat file.

4. Look up the field and error. Find the field number in the LEDES error code reference, then find the error number within that field. Read the row that matches your file format. If the same field appears more than once, use the entry that applies to your file.

5. Read what the document says to fix. The code leads to the fix, so read the full entry, not just the short error text. ( LEDES Oversight Committee, LEDES Error Codes)

6. Find every place the problem appears. The rejection may name one field, but the same issue can show up on several lines. Check each line where that field appears. A fix that corrects one line and leaves the others alone will produce another rejection.

7. Fix the source, then regenerate the file. Correct the data in your billing system and export again where you can. Hand edits are easy to get wrong, especially in a flat file, where a stray space or a shifted column can break the whole structure. Fixing the source also corrects the next export.

8. Check the file before you resend. Confirm that the field and error you targeted are gone and that nothing else changed by accident. If your billing software has a validation step, use it. If the client publishes submission instructions, follow them.

9. Resend and record what you did. Send the corrected file the way the client asks. Then write a short note with the date, the full error message, the field and error numbers, and which lines you changed. The next time a similar code appears, that note will save you a full search.

A worked example

Suppose a client rejects an invoice with the message "Bulk billing not allowed [1012-0053]." Here is how the steps apply.

First, split the code. The field is 1012, the time entry description. The error is 0053, bulk billing. Second, confirm the format. Suppose your file is XML. Look up field 1012 in the reference and find the entry for error 0053 in the XML row. Third, read the fix. The error text says bulk billing is not allowed, and the reference entry shows what the client's system checks for in that field.

Then go through your file and look at every time entry description the rejection could apply to. You are not hunting for random typos. You are looking for descriptions that the error covers. Correct them in your billing system, export again, and check the new file before you send it.

The two parts of the code are worth separating. If you had read only the message text, you would know that bulk billing was the issue but not which field held the problem, and you might have checked the wrong part of the file. The field number narrows the search, and the error number explains the rule that was broken.

Common causes and how to avoid them

Each of the three causes has a practical fix you can build into your routine.

Missing required fields. Keep a checklist of the fields your client requires and compare it against each file before you send. A blank required field may cause the system to reject the whole file, so a quick scan catches many problems early.

Inconsistent coding. The same kind of work should carry the same code every time. TimeSolv's guide notes that "These task and expense codes help categorize work consistently, which improves how invoices route through approval and reduces back-and-forth during review." ( TimeSolv, LEDES Billing Guide for Lawyers) Consistent codes also make your own mistakes easier to spot. For a related check, see our chart of accounts checks.

Line items that break the client's rules. A line can be accurate in your records and still break a rule the client set. Read the client's billing guidelines carefully, especially on how work is described, grouped, or recorded. When a rejection points to a description or grouping issue, check those guidelines first, then the reference entry.

Prevent the next rejection

The fastest way to handle rejections is to have fewer of them. Three habits help.

First, record each client's required format and version in writing, next to the client's name. A file that works for one client may fail for another, and whoever prepares the next invoice should not have to guess.

Second, review a sample before sending a full batch. For a wider review, see our invoice approval checklist. A problem that appears in one file often appears in the rest, so catching it early saves you from sending a stack of rejected files.

Third, keep a rejection log. Over a few months it will show patterns. If one code keeps coming back, the cause may be a setting in your billing software or a habit in how entries are written. Fixing the habit prevents rejections instead of repairing them one at a time.

A short checklist

When a client sends back a rejected LEDES file, work through these questions in order:

• Did I copy the full error message, including the bracketed code?
• Did I split the code into a field number and an error number, written exactly as shown?
• Do I know whether I sent XML or a flat file?
• Did I find the field and error in the reference document, reading the row that matches my format?
• Did I read the full entry for what needs fixing?
• Did I find every line where the problem appears?
• Did I fix the source data and regenerate the file, rather than only editing the output?
• Did I check the corrected file and record what I changed before resending?

If you can answer yes to each question, you have checked every part of the rejection. The code tells you where to look and what kind of problem you are fixing. Read it carefully, match it to the right format, and fix the cause rather than the symptom. Once that becomes routine, a rejected LEDES file becomes a short, specific task.