Category: LEDES API Project

It was about six years ago when Nick Puschak, then the Standards Director for the LEDES Oversight Committee, suggested that the organization create an API. The Board agreed that something was needed to create a more efficient legal ebilling process for law firms and to help manage the volume of tasks that need to be completed in the monthly billing cycle.

The first version of the API, created with Nick leading the effort, was ratified and released to the public in 2020 and, shortly thereafter, the subcommittee began working on version 2 of the standard again under Nick’s leadership.

It should be noted that LEDES does not have paid employees. All of our standards efforts are led by volunteers who donate their time.  Our subcommittee efforts are often delayed due to competing priorities related to our volunteers’ day jobs.  Nick’s retirement in 2022 also presented an additional hurdle with completing the standard.

Fortunately the LOC identified another volunteer to assume the role of Subcommittee Chair, Sherry Askin. We reestablished the subcommittee, reviewed the work completed under Nick’s leadership, and then considered other functionality which needed to be included in this release. By late summer, 2023, the documentation was finalized and a Public Comment survey was established to collect feedback on the standard from the legal community. Once the Public Comment period ended, the final documents needed another look.

Still to do: in January we will submit the final documents to the LEDES Standards Director for review, then to the LEDES Board for ratification.

So what is in API v2 Functionality?

• It changes the names of some common terms in legal ebilling (Client is now Business, Law Firm is now Vendor), in recognition that there are multiple types of entities that could be filling these roles.   
• It is intended to facilitate system-to-system transmission of information between the vendor (f/k/a law firm) users and the business (f/k/a Client) systems they are required to use. 
• While the API supports the transmission of the LEDES 98B, 98BI, XML Ebilling 2.0x, 2.1x and 2.2x formats.  LEDES 2000, officially dropped from support by the LEDES organization in 2022, is not supported.
• The API also establishes a JSON ebilling format that includes each of the data elements found in LEDES 98BI and XML 2.2x but is structured differently than either of these formats.
  • It is intended that the JSON invoice will be machine generated and not manually edited.
  • It is intended that the JASON invoice will only be utilized by the API and not by vendors submitting invoices via other means.  
• The API supports the following objects and functions:*

Object	Function
Business	Send Business information
Business	Get Businesses
Business	Get Business Information
Vendor	Send Vendor information
Vendor	Get Vendors
Vendor	Get Vendor Information
Location	Send Location
Location	Get Location information
Matter	Send Business Matter Info
Matter	Get Matters
Matter	Get Matter Information
Timekeeper	Send Timekeeper Info
Timekeeper	Get Timekeeper Info
Timekeeper	Send Timekeeper Rates
Timekeeper	Get Timekeeper Rates
Timekeeper	Send Proposed Timekeeper Rate Status
Timekeeper	Get Proposed Timekeeper Rate Status
Invoice Automation	Send Invoice (LEDES JSON)
Invoice Automation	Get Invoices (LEDES JSON)
Invoice Automation	Get Invoice (LEDES JSON)
Invoice Automation	Resubmit invoice
Invoice Automation	Appeal Invoice
Invoice Automation	Adjust Invoice
Invoice Automation	Send Invoice Attachment
Invoice Automation	Get Invoice Attachments
Invoice Automation	Get Attachment with information
Invoice Automation	Send the status of an invoice
Invoice Automation	Get the status of an invoice
Invoice Automation	Get invoice status changes
Invoice Automation	Invoice Payment
Invoice Automation	Invoice Payment
Invoice Automation	Delete Invoice
Invoice LEDES File	Send Invoice LEDES file
Invoice LEDES File	Send Invoice LEDES file Accrual
Invoice LEDES File	Send Invoice LEDES file Shadow
Invoice LEDES File	Send Invoice LEDES file Resubmit
Invoice LEDES File	Send Invoice LEDES file Appeal
Invoice LEDES File	Send Invoice LEDES file Replace
Invoice LEDES File	Send Invoice Attachment
Invoice LEDES File	Get Invoice Attachment
Invoice LEDES File	Send the Status of an Invoice (LEDES file based)
Invoice LEDES File	Get the Status of an Invoice (LEDES file based)
Invoice LEDES File	Get Invoice Status Changes
Invoice LEDES File	Invoice Payment
Invoice LEDES File	Invoice Payment
Invoice LEDES File	Delete Invoice

*Information from LEDES.org

We are very excited about the potential of the API and the impact it can have on law firm efficiency.   However, it needs to be developed and released before any impact will be felt.

The only way this happens is for vendors to embrace the API and make it part of their system functionality.  Here’s what I have seen:  the law firm system vendors (back-office financial and time and billing systems that already create LEDES invoice files) are eager to provide the API to their users.  The reception by the third-party ebilling vendors has been much more lukewarm, with an undertone of “what’s in it for us?”  So if you feel this functionality is important, particularly if you are a Business/Client that requires legal ebilling, please reach out to your ebilling vendor to discuss their plans to add the API.  

Look for more information on the API on www.LEDES.org.

I am part of a very small team that is finalizing version 2 of the LEDES API.  Led by Sherry Askin and Robert Kraai, the rest of the team includes Jim Hannigan and me.

Background

The idea for creating an API was the suggestion of Nicholas Puschak, a member of the LEDES Board of Directors, in 2018.  He envisioned a process that would facilitate system to system transmission of ebilling and other data required by law departments and other legal organizations that mandate their legal vendors to ebill.  The original idea was that API should allow law firm time and billing applications to communicate directly with the corporate legal department matter management and ebilling systems which would, in turn, allow law firm billing clerks to simply work within their time and billing applications to view the status of an invoice and to submit invoice, accruals and other legal data from within a single application without needing manual processing.  Nick led the effort working with a diverse group of subcommittee volunteers.  In February, 2020 version 1 of the API was released by the LOC. 

That we know of, only one law firm system, BILR by LSG, has implemented v.1 of the API; no ebilling vendors have implemented the standard.

Work on v.2 of the standard began organizing in June, 2020 again under the leadership of Nick Puschak.  The mandate was to look at issues noted in the original version and expand the functionality of the API.  Sadly, Nick’s retirement required a change in leadership and beginning in March 2023, new Co-Chairs were identified:  Sherry Askin and Robert Kraai, and a much smaller group has been meeting to work on the v.2 functionality 3 times a week since March, usually for 6-12 hours per week.

Like API v.1, API v.2 utilizes JSON, an open standard file and data exchange format. 

API v.2

API v.2 changes the name of some objects traditional to legal ebilling (business not client; vendor not law firm), reimagines the legal ebilling invoice structure (it is not visibly a relational database structure, instead it uses machine logic), and includes an automated JSON invoice format.

The updated draft v.2 specification includes the following functionality:

• The ability for businesses to provide their information; for vendors to get information on all businesses within the system that require them to ebill; and for vendors to get information on a specific business requiring them to ebill.
• The ability for vendors to provide their information; the ability for businesses to get information on vendors they require to ebill; and to get information on a specific vendor.
• The ability to send or get location information.
• The ability for businesses to send limited matter information; for vendors to get a list of matters assigned to their firm; and for vendors to get information on a specific matter.
• The ability for vendors to send timekeeper profile information and to request profile information for a specific timekeeper.
• The ability for vendors to send timekeeper rate information and to request rate information, including the status of rate approval, for a specific timekeeper.
• For LEDES Invoice files, the ability to send an invoice, accrual or shadow invoice; the ability for the vendor to resubmit or replace an invoice; the ability of the vendor to send or get an invoice attachment; the ability of the business to send and for a vendor to get the status of an invoice; the ability of the business to send and for a vendor to get payment information; and the ability of a vendor to delete an invoice that has not yet been reviewed by the business. 
• A new JSON ebilling format for use only by the API that includes the following functionality: the ability of the vendor to submit an automated invoice, to get id information on invoices sent and the ability of the vendor to query the status of a specific invoice; the ability of the vendor to resubmit an invoice; the ability of the vendor to appeal an invoice; the ability of the business to provide adjustment information on an invoice; the ability for the vendor to send an invoice attachment, for the vendor get an a list of invoice attachments, or for the vendor to get a specific invoice attachment; the ability of the business to send the invoice status, for the vendor to get a list of invoice statuses or for the vendor to get information on a specific invoice status; the ability for the business to send and the vendor to get invoice payment information; and the ability of the vendor to delete an invoice that has not yet been reviewed by the business.

We will be discussing the API in an educational session at ILTACon in August.  Check back for more information on the ILTA session, and the next steps toward ratification of the standard.

In October I wrote about the LEDES API initiative, for which version 2 is expected to be released in the next couple of months. To encourage development of the API, the LEDES Oversight Committee (LOC) will create an API testing platform and make this available to vendors in the legal space. A survey has been posted to establish a timeline for making the test platform available. Please go to https://www.surveymonkey.com/r/LEDES_API_Survey to access the survey.

Below is background on the testing platform and project.

_________________________________

The purpose of the LEDES API is to facilitate system to system communication directly from the law firm to the third-party ebilling vendor. The API will facilitate the transmission of data files from the law firm to the ebilling vendor and accept notifications from the ebilling vendor back to the law firm.

 Why an API? Legal ebilling is extremely time-intensive to support at the law firm. The API will ease the burden at the law firm by automating transmission and notification processes where possible. A unified LEDES API will allow vendors to implemented solutions more quickly than if a custom API is required for each of the dozens of ebilling solutions in the marketplace. 

It is expected that several versions of the LEDES API will be released by the LEDES Oversight Committee over time, with each new version increasing the functionality supported by the API. V2 of the API is expected to be released in 2022. 

To facilitate the creation of these API connections, the LEDES Oversight Committee will create a testing platform for vendors to test their API functionality.  

Use-cases have been defined by the LEDES Oversight Committee to ensure the full breadth of functionality of the LEDES data exchange formats is supported by both types of systems. The LEDES Oversight Committee will provide written documentation to setup the test environment, including test clients, test law firms with timekeepers and rates, and test matters. Using this information, file transmissions supporting the use-cases will be tested, and based on the performance of the systems, the LEDES Oversight Committee will be able to score the quality of the API supported by the system, enforcing compliance with the full feature set supported by the LEDES formats. 

The LEDES Oversight Committee has selected LogicShark to build and support the test environment. LogicShark helps organizations design and implement digital transformation strategy to facilitate organizational change by using their low-code, application development software, the LogicShark CNECT Platform. Of importance to the LEDES Oversight Committee, LogicShark does not offer law firm or law department systems that utilize LEDES standards and is fully independent in this regard.

Understanding that vendors need to place the API on their development roadmap and secure funding and resources for its development, once the test environment goes live, it will be supported by the LEDES Oversight Committee for a minimum of five years. 

 It is important for the law firm back-office systems to consider how information can be incorporated into their data set. For example, it will be possible to

• Note the date an ebill was submitted
• Provide the current status of an ebill submission.
• Note the amount approved for payment by the client
• Calculate, based on the date a payment request is sent to Accounts Payable plus the days-to-pay specified by the client, an estimated date on which payment is expected
• Note the actual date paid, plus the check number, transaction ID or other information associated with the payment provided by the ebilling vendor

 Definitions

System to system. We do not anticipate “home-grown” connections from the law firm to the ebilling vendors. Our intention is that the law firms’ back-office software (financial, time and billing, timekeeping, etc.) which generates LEDES invoice files would be the source of the law firm API. 

It may be the case that middleware could be developed as a transmission point from the law firm to the ebilling vendor, enabling support for smaller global firms that do not have the benefit of western-style back-office systems. We find it unlikely, however, that larger firms that have western-style back-office software would use this type of connection.

Notifications. The type of notifications from the ebilling vendor envisioned are those currently sent via email or via posted in the ebilling system. These include, but are not limited to, invoice submission results, rejection information, payment confirmation information, accrual requests, timekeeper/rate approvals, etc.

Increasing Functionality. v1 of the API supports the transmission of LEDES invoice files and the return of notifications on these submissions, and the ability for law firms to request the status of invoices. v1 assumed that when a legal service provider application communicates with an e-billing system it would require separate credentials for each client with which it would want to exchange information.

In v2, we are adding the ability to only require one set of credentials when communicating with an e-billing system and support a call to identify the clients for whom the legal service provider is exchanging information, facilitating more easily the submission of invoices to a specific client. The request to get the status of a set of invoices has been changed to use a “Modified Since” date/time instead of requiring the third-party ebilling vendor to support an “InvoiceStatusMarker.”   

The API subcommittee has also done some preliminary work to establish a JSON LEDES file format based on XML 2.2 and calls to exchange matters, timekeepers and rates, however these specific processes may be put off to a v3 release.

(This post was also shared on LinkedIn.)

As many are aware, I have led the LEDES Oversight Committee (“LOC”) for many years now. We have a project underway that could solve some significant law firm ebilling problems and I would like to use this forum to spread the word.

Let’s talk about the problems. 

A law firm’s time and billing software is set up to capture the date an invoice (i.e., a paper bill) was generated. But with ebilling, that is only the first step. The biller must then create a LEDES invoice file, and then log into the client’s ebilling system, upload and submit the invoice and attachments, and then wait for information on whether the invoice has passed electronic validation or not. Typically, this happens in a relatively short period of time from when the paper bill was generated. But if the invoice is rejected during electronic validation, there can be a cycle of correction/resubmission until the invoice is accepted by the system. Once accepted, the bill reviewer can also reject the invoice, which starts off another cycle of correction/resubmission until the invoice is finally approved for payment.  

In ebilling, the date an invoice is accepted is equal to the date the paper bill is generated but there can be a delta if the invoice has been rejected and requires correction/resubmission. Since time and billing software is totally disconnected from ebilling, it does not pick up information on when an invoice has been accepted by the ebilling system, nor does it provide information on invoice status, particularly on rejections that need correction.

To compound the situation, most clients have rules specifying the maximum number of days to submit services and expenses for payment. This means that an entire invoice can be rejected if the invoice end date exceeds the specified time period, or individual time or expenses can be rejected based on aging. With no recourse for getting paid, the law firm must write off the time and expenses. 

As if that wasn’t bad enough, Law Firm collection software uses the date the paper bill was created for collection action on overdue invoices. Billers must check whether the client is an ebilling client and, if so, follow up on the invoice status prior to taking any collection action. In many cases this is the point where the law firm learns that a rejected invoice has not been corrected/resubmitted and may have exceeded the client’s submission criteria.

When I say these are big issues for law firms, I mean BIG!

So now let’s talk about how the LOC is working on something that could solve these issues. 

We started an effort led by Nick Puschak a couple years ago to create an API to allow for system-to-system transmission of ebilling invoices and provides calls for updates on invoice status. The first version of the API was released in 2020 and can be found here: LEDES API – LEDES.org. 

Nick started version 2 discussions earlier this year with the intention of dramatically expanding the scope of tasks that the API can handle. 

With respect to invoice status, the calls proposed in v.2 at this time will identify: 

• received:  Receiving system has simply received the Invoice, however no file error processing or other actions have occurred at this time. The invoice will stay in this state until the file error checking has been completed.
• file_error:  There are errors in understanding the invoice data. The invoiceErrors array should list the errors. If no file errors are found then the status should be set to one of the following statuses, which will imply that the invoice data was understood. Even though there may be no file errors found, this does not mean there are no errors in the invoice and it still may be rejected due to some automated audit checks or manual checks by a user.
• pending_client:  The receiving system understands the invoice and it is pending review or future action by the client.
• pending_tax_authority:  The receiving system understands the invoice and it is pending approval from the tax authority, when that is required.
• pending_vendor:  The receiving system understands the invoice and the invoice is awaiting a response for some action from the Vendor. For example, if the client needs a receipt attachment to be submitted. 
• delivered_to_client:  The receiving system has delivered the invoice to the client system. This optional status can be used when the invoices is passed to a separate client system.
• rejected:  The receiving system has rejected the invoice with errors. The invoiceErrors array should list the errors.
• approved:  The invoice was approved by the receiving system or by users and its awaiting payment.
• sent_to_ap:  The invoice was sent to an Accounts Payable system.
• paid:  The invoice was paid. The invoicePayment array should list any payment data. On some systems the receiving system may not receive payment data or even a paid status.

Think about it. It will be possible to either support an additional field or update the paper bill create date to reference the date the invoice has been accepted by the ebilling system and a new Ebill Invoice Status field can be updated to provide information on ebill status. Think about the potential of having a report showing invoices with Rejected status that need correction/resubmission! 

What I envision requires a commitment on the part of the time and billing vendors and the ebilling vendors to add this functionality. My hope with this post alerts these vendor communities to the API effort, that they consider joining the LOC to participate in the API development, and they look for the release of the API v.2 so that API support and associated updates within their systems can be immediately rolled out to their customers. 

(This post was also shared on LinkedIn.)