This is an important update, please read this post completely to the end.
The LEDES Oversight Committee Board of Directors is pleased to announce the ratification of updates to the XML Ebilling formats, with new versions released for XML Ebilling 2.0.4, XML Ebilling 2.1.4 and XML Ebilling 2.2.1.
The newly ratified versions deliver a number of important features.
First, we had identified a few fields that simply needed updating. For example, there are UTBMS code sets having codes that are more than 4 characters in length and the format specification documents as written did not reflect this reality.
Next, in the past after XML Ebilling 2.0 was released and we identified the need for updates, XML Ebilling 2.1 was released that included numerous data elements that were not included in 2.0. Similarly, 2.2 was released with additional functionality that didn’t appear in 2.0 and 2.1. We found there is a reliance on XML 2.0 which is inadequate for a number of situations. Why? Both the billers and the ebilling vendors have not updated their systems to include the additional functionality of the higher versions. Equally frustrating, we learned that some client systems require data added to the @EXTEND_HEADER and @EXTEND_DATA segments that already appear within the 2.0.3, 2.1.3 or 2.2 data strings. Why? These vendors have developed the ability to import the XML formats limited to the fields associated with LEDES 98BI and not the full functionality of these more comprehensive legal ebilling formats. For these reasons, the Board decided to align the base fields in the three formats so that 2.0.4 becomes a much more versatile solution. Yes, there are still situations where XML 2.1.4 or 2.2.1 is needed, but now XML 2.0.4 provides a more versatile invoice data stream.
This table below shows the data element differences between the formats (Black coloring indicates no associated field): 
Finally, as we were working on the updates, it came to our attention that there was a rate approval issue that could be easily solved by the addition of a few fields and the modification of 1 or possibly 2 validation rules, depending on how the client system is written, plus the addition of 2 new validation rules. Everything else that existed previously in every vendor system works exactly the same as it did previously. See the format pages for more information on the changes needed for this new rate approval feature to work.
Let’s illustrate the issue: Lets say that a timekeeper is US-based and also provides services in the UK. The US timekeeper has a rate in USD and the ebilling vendor systems assumed that the timekeeper would have a single rate in GBP. But this isn’t always the case. Many firms establish the GBP rate by multiplying the USD rate by exchange rate to GBP. That works fine until the exchange rate changes, at which time the firm needs to put through another rate approval for the new USD*GBP exchange rate amount. It is possible, then, over the course of preparing monthly bills for their client, that 12 different rates require approval for each US timekeeper working on that matter billed in GBP. The need to check exchange rates and rate approvals is extremely time consuming. Just as inefficient, clients find themselves needing to approve rates every month instead of considering rate requests once per year (as is the Best Practice).
With 2.0.4, 2.1.4 and 2.2.1, once clients have updated their systems, this aspect of rate management will be much easier and more efficient for all involved parties. Law firms are cautioned to check with their client vendor system to determine whether the new schema has been released before implementing this change else a validation error will occur.
The LEDES Board encourages all law firms that ebill and all law departments and other legal organizations that require their outside counsel to ebill to urge their vendors to develop the new capabilities of this release as soon as possible.