Earlier this year, the LEDES Oversight Committee proposed revisions to the LEDES XML 2.0x, 2.1x and 2.2 ebilling standards. The Public comment period for these changes closed on July 25, 2022 and there were no objections to the proposed changes.
While preparing the final paperwork to ratify these changes, additional discussion was held on deficiencies that needed to be corrected in the XML formats and the documents presented here reflect these additional requested changes. The survey to provide feedback can be found here. Below is the revised format documentation.
[download id="14581"][download id="14584"][download id="14587"]
Discussion
The LEDES Oversight Committee would like to align the math statements between the three XML ebilling formats. This involves very little updating in XML 2.1x, however quite a bit of updating in XML 2.0x. By doing this, XML 2.0x will, with the exception of 3 fields, will contain exactly the same base fields and the same math statement as XML 2.1x and 2.2x.-
- XML 2.1x will contain everything in 2.0x plus some additional fields, which make this format appropriate to use in certain situations.
- XML 2.2x will contain everything in 2.1x plus some additional fields, which makes this format appropriate to use in other situations
Why align the formats?
Currently we have LEDES 98BI and LEDES 98B. Both have exactly the same base 98B fields, plus other fields for 98BI. We would like the XML formats to work the same way.What is the consequence of aligning the formats?
Vendors will need to update their platforms for this to work as we intend. Historically vendors have been slow to provide new LEDES ebilling functionality on their platforms. Buy-in from clients mandating ebilling and law firms required to ebill will be necessary to compel vendors to update their systems.- Currently developers can create routines for 98BI, and then strip back the routines to remove the 98BI fields that are not part of 98B. We would like the XML formats to work the same way and expect that this will ultimately make developers jobs easier. Developers will be able to create routines for XML 2.2x, and then strip back the routines to remove the 2.2x fields that are not part of 2.1x. Ditto for 2.0x.
- The LEDES Oversight Committee would like to preserve the ability for ebillers to continue using the lowest format version possible into the future. This means updating XML 2.0x specifically to pick up fields of information necessary that have been added to XML 2.1x and @2.2x which are now commonly necessary to ebill. An example here are the fields that support global Continuous Tax Control systems that are increasingly enacted by Tax Authorities around the world. By adding these fields to XML 2.0x, ebillers are then able to continue using that format in these countries when appropriate.
- Global ebillers indicate a need for the formats to include more than one non-local currency within an invoice (for example, include USD and EUR in an GBP invoice). Further, this issue may be limited to just including line items for a single timekeeper in multiple currencies. Currently the LEDES Formats are limited to including only one non-local currency in an invoice and the proposed changes will fix this.
- Global ebillers indicate that a need for the formats to include an invoice exchange rate and the invoice exchange rate date. The invoice exchange rate is often requested to be included in the @INVOICE.EXTEND_HEADER section. Due to the frequency with which it is requested, Global Billers request this be a permanent addition to the format. The invoice exchange rate date may be contractually mandated (like the last day of the month previous to when the services were provided), and helps the receiving system identify which exchange rate should be used for validation. Both fields are included in the proposed changes.
- Global billers indicate that it is often the case that foreign timekeeper rates (i.e., in a currency other than the timekeeper's home currency) are often not a flat rate but are instead the product of the timekeeper's home rate multiplied by the current exchange rate. They request revision of the formats to include the exchange rate associated with the timekeeper rate and the timekeeper's exchange rate date. Both fields are included in the proposed changes.
- Global ebillers have indicated that timekeeper rate checking, as it is currently handled by the Ebilling System Electronic Validation routines is problematic. At a 1000' level, timekeeper rate entry currently requires a Timekeeper ID, their classification, a rate, a currency, and rate start and end dates. [Note: in lieu of rate start and end dates, the system may only look at "active" rates.] This schema works well when the timekeeper has a flat rate. For example, the home currency usually always has a flat or set hourly rate, but there could be multiple active rates depending on the type of service performed by the timekeeper. Rate checking in this situation works well. As previously described, however, rate checking does not work well when rates are subject to variation depending on the current exchange rate, and this is especially true when rate start and end dates are not hard-coded during rate entry. Because the exchange rate may vary since the last invoice submitted,
-
- Each time invoices are created Timekeeper Invoice Rates must always be checked in the EBS to be sure they have been approved
- System lists of active, approved timekeeper rates can be very long, making searching difficult
- If not in System, the law firm must add and Client must approve new rates, which is burdensome to both parties
- If the rate has been added but is not yet approved, the law firm must follow up with Client
- Finally, because the time to approve new rates may impact the Client's aging requirements submitting invoice line-items, this can result in the potential loss of firm revenue.
With this in mind, the LOC has proposed moving rate validation off of the timekeeper's invoice rate (@TKSUM.tk_rate or @FEE.tk_rate) to a new field that shows the timekeeper's home currency before the exchange rate has been applied (@TKSUM.tk_rate_other_iso). The instructions make this new field required for all invoices and, in situations where there is a single currency invoice, the timekeeper's invoice rate must equal the timekeeper's home rate.
This solution also requires one other validation rule, to validate that the timekeeper's invoice rate equals the timekeeper's home rate multiplied by the timekeeper's exchange rate.
Please keep in mind that this solution requires the removal of possibly 2 rules and addition of 2 rules to every client ebilling system, so the LOC will need Clients mandating ebilling to push the vendor systems to make these changes. The proposed changes include all of these elements.
Below is the full list of changes requested in the proposed formats.
XML Ebilling Ver 2.2.1
- Numerous fields adjusted in Column E to clarify that the value is required only if the segment is used or to better explain conditional use; this is for programmers to better understand when a segment can be dropped from the file created.
- Numerous money fields updated in Column E to identify the currency represented in the event of a multi-currency invoice.
- @TAX.withholding_tax (field 22) added and field numbers adjusted for all following fields.
- @INVOICE.inv_currency (field 35) edited for clarity.
- @INVOICE.inv_other_iso (field 36) changed to required and instructions provided.
- @INVOICE.inv_reference (field 52) field deleted and replaced by @INVOICE.inv_ref_credit_note (field 52), which deals only with the invoice reference for Credit Notes, @INVOICE.rejected_inv_replacement (field 53), a new field, and @INVOICE.inv_ref_rejected_inv_replacement (field 54), which deals only with the invoice reference of a previously rejected invoice.
- @INVOICE.total_withholding (field 58) and @INVOICE.total_withholding_other_iso (field 59) added.
- @INVOICE.exchange_rate (field 64) and @INVOICE.exchange_rate_date (field 65) added.
- @TAX_TIER_DETAIL Note on line 91 edited for clarity.
- @TAX_TIER_DETAIL fields 69-74 edited to reflect illustration on line 91.
- @TAX_TIER_DETAIL.tax_tier_min (field 75) Note corrected.
- @TAX_TIER_DETAIL.tax_tier_max (field 76) instructions changed to support ease of import.
- @TKSUM.rate (field 134) updated significantly for usage and vendor instructions added.
- @TKSUM.tk_rate_other_iso (field 135) added and vendor instructions included.
- @TKSUM.tk_other_iso (field 136), @TKSUM.tk_exchange_rate (field 137) and @TKSUM.tk_exchange_rate_date (field 138) added.
- @FEE.task_code (field 147) and @FEE.task_activity (field 148) adjusted to 10 character length.
- @FEE.rate (field 151) updated significantly for usage and vendor instructions added.
- @EXPENSE.task_code (field 172) and @EXPENSE.expense_code (field 173) adjusted to 10 character length.
XML Ebilling Ver 2.1.4
- Numerous fields adjusted in Column E to clarify that the value is required only if the segment is used or to better explain conditional use; this is for programmers to better understand when a segment can be dropped from the file created.
Numerous money fields updated in Column E to identify the currency represented in the event of a multi-currency invoice. @TAX.withholding_tax (field 21) added and field numbers adjusted for all following fields.
- @INVOICE.inv_currency (field 34) edited for clarity.
- @INVOICE.inv_other_iso (field 35) changed to required and instructions provided.
- @INVOICE.inv_reference (field 51) field deleted and replaced by @INVOICE.inv_ref_credit_note (field 51), which deals only with the invoice reference for Credit Notes, @INVOICE.rejected_inv_replacement (field 52), a new field, and @INVOICE.inv_ref_rejected_inv_replacement (field 53), which deals only with the invoice reference of a previously rejected invoice.
- @INVOICE.total_withholding (field 57) and @INVOICE.total_withholding_other_iso (field 58) added.
- @INVOICE.inv_image_file_name (field 62) added to align with XML 2.2x.
- @INVOICE.exchange_rate (field 63) and @INVOICE.exchange_rate_date (field 64) added.
- @REGULATORY_STATEMENT.regulation_heading (field 67) size increased.
- @TKSUM.rate (field 121) updated significantly for usage and vendor instructions included.
- @TKSUM.tk_rate_other_iso (field 122) added and vendor instructions included.
- @TKSUM.tk_other_iso (field 123), @TKSUM.tk_exchange_rate (field 124) and @TKSUM.tk_exchange_rate_date (field 125) added.
- @FEE.task_code (field 134) and @FEE.task_activity (field 135) adjusted to 10 character length.
- @FEE.rate (field 138) updated significantly for usage and vendor instructions added.
- @EXPENSE.task_code (field 159) and @EXPENSE.expense_code (field 160) adjusted to 10 character length.
- @EXTEND_DATA.file_item_nbr (field 203) added to align with XML 2.2x.
XML Ebilling Ver 2.0.4
- Segment Notes in Column G updated to align with XML 2.1x and XML 2.2x (text modified only, no substantive changes).
- Numerous fields adjusted in Column E to clarify that the value is required only if the segment is used or to better explain conditional use; this is for programmers to better understand when a segment can be dropped from the file created.
- Numerous money fields updated in Column E to identify the currency represented in the event of a multi-currency invoice.
- @CLIENT.cl_name (field 20) sized updated to align with XML 2.1x and XML 2.2x.
- @INVOICE.inv_currency (field 29) edited for clarity.
- @INVOICE.inv_other_iso (field 30) field added to align to XML 2.1x and XML 2.2x, and field numbers adjusted for all following fields.
- @INVOICE.inv_desc (field 33) size updated to align with XML 2.1x and XML 2.2x.
- @INVOICE.rejected_inv_replacement (field 34) and @INVOICE.inv_ref_rejected_inv_replacement (field 35) added.
- @INVOICE.inv_payment_terms (field 36) size updated to align with XML 2.1x and XML 2.2x.
- @INVOICE.inv_image_file_name (field 42), @INVOICE.exchange_rate (field 41) and @INVOICE.exchange_rate_date (field 44) added.
- @MATTER.matter_desc (field 50) field size increased to align with XML 2.1x and XML 2.2x.
- @MATTER.matter_billing_type (field 54) updated to include MPF to align with XML 2.1x and XML 2.2x.
- @MATTER.matter_disc_credit_fees (field 58) and @MATTER.matter_disc_credit_exp (field 59) updated to include MIFA instruction to align with XML 2.1x and XML 2.2x.
- @MATTER.matter_perc_shar_fees (field 61) and @MATTER.matter_perc_shar_exp (field 62) field size increased to align with XML 2.1x and XML 2.2x.
- @MATTER.matter_disc_bill_pct_fees (field 63) and @MATTER.matter_disc_bill_pct_exp (field 64) added to align with XML 2.1x and @XML 2.2x.
- @MATTER.matter_funds_applied (field 65) added to align with XML 2.1x and XML 2.2x.
- @MATTER.matter_total_due (field 70) updated to include matter_funds_applied, to align with XML 2.1x and XML 2.2x.
- @MATTER_DISC_CRED.disc_cred (field 80) allowed values updated to include MIFA to align with XML 2.1x and XML 2.2x.
- @TKSUM.tk_rate (field 95) updated significantly for usage and vendor instructions included.
- @TKSUM.tk_rate_other_iso (field 96) added and vendor instructions included.
- @TKSUM.tk_other_iso (field 97) and @TKSUM.tk_exchange_rate (field 98) added.
- @FEE.charge_desc (field 104), @FEE.task_code (field 107) and @FEE.task_activity (field 108) size increased to align with XML 2.1x and XML 2.2x.
- @FEE.rate (field 111) updated significantly for usage and vendor instructions added.
- @EXPENSE.charge_desc (field 130), @EXPENSE.task_code (field 131) and @EXPENSE.expense_code (field 132) size increased to align with XML 2.1x and XML 2.2x.
- @ADDRESS_INFO.country (field 155) instructions changed to align with XML 2.1x and XML 2.2x.
- @EXTEND_DATA.file_item_nbr (field 173) added to align with XML 2.2x.
If these changes are ratified, below are the differences between the XML formats.
