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