Author: Jane A. Bennitt

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.