100% of survey complete.
The purpose of this survey is to gather public comment on proposed revisions to the LEDES XML 2.0x, 2.1x and 2.2 ebilling standards.  The LEDES Oversight Committee posted proposed revisions to these three formats back in June.  [Note:  the earlier proposed revisions appear at the bottom of this window.] However, additional issues have come to light that require additional public comment.

A copy of the proposed changes to the three XML ebilling formats can be found here, along with documentation on the differences between the field structure of the three XML ebilling formats, and a full list of the proposed changes to the formats.

This survey will close on December 9, 2022.
Earlier Proposed Changes for Which There Was No Objection

XML 2.0.4 Rev. 6/2022:
- @INVOICE.inv_payment_terms (field 33) updated to align with XML 2.1x and XML 2.2x;
- @INVOICE.inv_image_file_name (Field 39) added to align with XML 2.2x and field numbers adjusted for all following fields;
- @INVOICE.exchange_rate (field 40) added;
- @FEE.charge_desc (field 93) updated to align with XML 2.1x and XML 2.2x;
- @FEE.task_code, @FEE.task_activity (respectively field 94 and field 95) adjusted to 10 character length;
- @EXPENSE.charge_desc (field 116) updated to align with XML 2.1x and XML 2.2x;
- @EXPENSE.task_code and @EXPENSE.expense_code (respectively field 117 and row 136/field 118) adjusted to 10 character length

XML 2.1.4 Rev 6/2022:
- @INVOICE.inv_image_file_name (field 58) added to align with XML 2.2x and field numbers adjusted for all following fields;
- @INVOICE.exchange_rate (field 59) added;
- @FEE.task_code, @FEE.task_activity (respectively field 125 and row 154/field 126), @EXPENSE.task_code and @EXPENSE.expense_code (respectively field 140 and row 185/field 151) all adjusted to 10 character length.

XML 2.2.1 Rev 6/2022:
- @INVOICE.exchange_rate (field 59) added and field numbers adjusted for all following fields;
- @FEE.task_code, @FEE.task_activity (respectively field 137 and row 172/field 138), @EXPENSE.task_code and @EXPENSE.expense_code (respectively field 162 and field 163) all adjusted to 10 character length.
Additional Proposed Changes Requested:  XML 2.0.4 Rev. 11/2022

- 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.
Additional Proposed Changes Requested:  XML 2.1.4 Rev 11/2022

- 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) field added to align with XML 2.2x.
- @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.rate (field 138) updated significantly for usage and vendor instructions added.
- @EXTEND_DATA.file_item_nbr (field 203) added to align with XML 2.2x.
Additional Proposed Changes Requested:  XML 2.2.1 Rev 11/2022
- 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_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.rate (field 151) updated significantly for usage and vendor instructions added.

Question Title

* 1. Name:

Question Title

* 2. Email:

Question Title

* 3. At which type of organization do you work?

Question Title

* 4. Do you work for a law firm required to ebill for at least one client or do you work for a Client that requires panel firms to ebill?

Question Title

* 5. 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.
  • And 2.2x will contain everything in 2.1x plus some additional fields. which makes this format appropriate to use in other situations. 
LEDES.org contains a page that explains "Which Format Should I Use?" and this will be updated when the format changes are finalized.

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. 

What is the consequence of aligning the formats?

Vendors will need to update their platforms for this to work as we intend, and we all know that 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 is 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 make developers jobs easier because key formats fields work similarly.  Developers can 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.  

Do you agree with aligning the formats?

Question Title

* 6. 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.

Do you agree with adding fields necessary to allow ebillers to use the lower XML ebilling formats into the future?

Question Title

* 7. 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.

Do you agree with allowing more than one currency in an invoice?

Question Title

* 8. Global ebillers indicate 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 ebillers 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.

Do you Agree with adding the invoice exchange rate and the invoice exchange rate date?

Question Title

* 9. Global ebillers 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.

Do you agree with adding the timekeeper exchange rate and the timekeeper exchange rate date?

Question Title

* 10. 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, th 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 on 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.      

Do you agree with changing the rate checking schema to better support situations where the timekeeper rate is based on their home rate multiplied by the exchange rate?

Question Title

* 11. Other than as specifically asked above in questions 5 - 10, do you agree or disagree with the proposed changes in LEDES_XML_e-Billing_2-0-4_Rev 11-2022 w Changes Marked from 2.0.3 Rev 1-2020.xslx?

Question Title

* 12. Please comment on the proposed changes in LEDES_XML_e-Billing_2-0-4_Rev 11-2022 w Changes Marked from 2.0.3 Rev 1-2020.xslx.  Is anything missing? Has anything been included that should not be?  Do you note any issues with the document?

Question Title

* 13. Other than as specifically asked above in questions 5 - 10, do you agree or disagree with the proposed changes in LEDES_XML_e-Billing_2-1-4_Rev 11-2022 w Changes Marked from 2.1.3 Rev 1-2020.xslx?

Question Title

* 14. Please comment on the proposed changes in LEDES_XML_e-Billing_2-1-4_Rev 11-2022 w Changes Marked from 2.1.3 Rev 1-2020.xslx.  Is anything missing? Has anything been included that should not be?  Do you note any issues with the document?

Question Title

* 15. Please comment on the proposed changes in LEDES_XML_e-Billing_2-2-1_Rev 11-2022 w Changes Marked from 2.2.xslx.  Is anything missing? Has anything been included that should not be?  Do you note any issues with the document?

Question Title

* 16. Other than as specifically asked above in questions 5 - 10, do you agree or disagree with the proposed changes in LEDES_XML_e-Billing_2-2-1_Rev 6-2022 w Changes Marked from 2.2.xslx?

T