ELM Systems Integration: What Needs to Connect

An enterprise legal management platform is only as valuable as the systems feeding (sending) it and receiving information from it. The platform itself stores matters, routes approvals, and holds invoices. What determines whether it becomes the legal department’s system of record, or an expensive place to file things after the fact, is the set of connections running into it and out of it.

World Commerce & Contracting’s 2023 benchmark found that contract data in medium and large organizations is scattered across an average of 24 systems. Legal work is no more concentrated.

The question worth answering before you shortlist a vendor is which of those systems has to connect, in what direction, and how you would know a connection was real. This article sits inside our broader work on enterprise legal management.

What systems does an enterprise legal management platform need to connect to?

The external systems an ELM platform needs to can be bucketed into four groups

1. Intake: Work has to get into the system. The legal service request portal, the upstream business systems that generate requests, and contract intake.
2. Spend: Money has to complete the loop. Approved invoices out to accounts payable, accruals back in.
3. Identity and Obligations: Who is allowed to do what. Single sign-on, the HR system of record, and legal hold.
4. Document Repository: Where the work product lives. The document repository and the e-signature platform.

The ordering can be adjusted but needs to accommodate dependencies. Accrual accuracy is meaningless if the work never came in as a matter in the first place. Custodian identification for a legal hold is painful if your org hierarchy lives in a spreadsheet somebody maintains by hand. Document management is incomplete if half the department still emails drafts. If you are new to the category, our primer on What Is Enterprise Legal Management (ELM)? covers the platform’s core modules before the connections between them.

How does legal work reach the ELM system in the first place?

Work reaches the ELM through a front door that the business can find without being trained. Usually that front door is a legal service request portal, and it is the single most consequential connection in the entire architecture, because everything downstream depends on work arriving in a structured form rather than in an inbox.

Email requests stay requests until something converts them into a matter. A request that arrives as a message to a lawyer’s personal inbox has no requester of record, no business unit, no intake date, no category, and no place in a workload view. It cannot be reported on, triaged, or reassigned when that lawyer takes leave. Our guide to Automate Legal Service Requests to Modernize Your Department covers the portal itself; the point here is what it must connect to.

In one global retailer program Swiftwater delivered, the request portal served as the nerve center for both intake and workload management across the legal function. Some requests were handled and closed inside the portal without ever becoming a matter, which is the correct outcome for a routine question. Others were triaged by legal leadership and converted into a matter, at which point they were assigned to a named attorney who took responsibility for the documents, correspondence, and data attached to that record. If the attorney chose to engage outside counsel, the preferred firms were already available in the record, which meant the engagement, the matter, and the eventual invoices shared a single matter-centric identifier from the first day.

OUTSIDE COUNSEL MANAGEMENT

Struggling to control outside counsel spend?

We help legal departments build the governance, billing guidelines, and analytics infrastructure to take back control. A 30-minute call is where it starts.

Book a Discovery Call

The upstream connection matters as much as the portal. A sales team requesting a contract review, a real estate team submitting a lease question, a procurement team routing a supplier agreement, and an HR team escalating an employment issue should each be able to originate a request from the system they already work in, or at minimum arrive at the portal already authenticated and already recognized.

In that retailer project that Swiftwater delivered, single sign-on meant a business user landed in the request form with their division, region, and cost center already populated. Nobody typed their own business unit, which is precisely why the reporting was trustworthy later.

Contract intake is a second front door running in parallel. Business requesters could take one of two paths: self-service, for standard agreements they could complete and execute with little or no legal involvement, or a request for legal engagement on anything complicated. Both paths ended in the same repository. The fork is the design decision, and it only works when the intake form is smart enough to route correctly.

The relationship between the request, the matter, and the outside counsel engagement is covered in What Is Matter Management in Legal?.

What to ask a vendor about arrival: Can a business user originate a request from Salesforce, ServiceNow, or Microsoft Teams without leaving that system? Does the vendor have a LSR solution?What are the differences between the external vs the LSR interface? When a request converts to a matter, does the original request record persist and stay linked, or is it replaced? Can a request be resolved and closed without becoming a matter, and does that closure still appear in workload reporting? Does the intake form pull the requester’s business unit, region, and cost center from identity rather than asking them to select it? Can intake route to a self-service path and a legal-engaged path from the same form based on the answers given?

What has to connect between the ELM system and finance?

The connection between the ELM and finance is what converts “we track our spend” into “finance trusts our numbers.” It runs in two directions and most departments only build one of them.

Outbound, approved invoices need to reach accounts payable. The invoice arrives from a law firm through the eBilling portal, gets reviewed against the outside counsel guidelines, gets approved or adjusted by the lead lawyer, and then has to become a payable in SAP, Oracle, Coupa, or whatever the enterprise runs. An invoice that stops inside legal has been reviewed and nothing more. The firm still calls to ask when it will be paid, and the answer still requires somebody to check a second system.

In the retailer engagement, delivered by Swiftwater, the eBilling implementation allowed firms to submit against the outside counsel guidelines directly, and allowed the responsible lawyer to approve and audit line by line. The connection that changed the department’s standing internally was different. Integrations pushed approved invoice data to finance divisions across the world in real time, the moment approval happened. Regional finance teams stopped asking legal for spend extracts, because the numbers were already in their systems on the same day.

The mechanics of guideline enforcement are in Outside Counsel Billing Guidelines: What to Include, and the implementation itself in Onit eBilling Implementation: What It Takes.

Accruals also need to be provided to Finance. Finance needs to know what legal will owe before the invoice arrives, which means the ELM has to collect accrual estimates from firms, roll them up by matter and by period, and deliver them to the general ledger on the close calendar rather than on legal’s calendar. This is the connection that gets skipped, and its absence is the reason so many legal departments are treated as an estimate rather than a line item. The broader case is made in Why eBilling Tools Alone Aren’t Enough.

Payment information or Purchase Order information is the inbound piece. Depending on your needs you may need one or both.

The cost of leaving this loop open is calculable. Time spent reconciling legal’s spend view against finance’s payables view, invoices sitting unpaid past terms, accrual variance that finance has to buffer against, and the recurring manual export that somebody does every month forever.

When creating a savings model, using legaltechcalculator.com, in addition to the savings from transparency and billing guideline enforcement, remember to include the efficiencies gained from eliminating the manual back and forth and delay in real-time decision making information.

What to ask a vendor about closure: Does approved invoice data reach the AP system automatically on approval, or does someone export a file? Is the AP connection a maintained native connector for SAP, Oracle, or Coupa, or is it custom middleware built once for your tenant? Do accruals flow back into the general ledger on the finance close calendar? When a firm asks about payment status, can a lawyer answer from inside the ELM without opening a finance system? Does an adjusted invoice send the adjusted amount downstream, or the original?

How do identity, HR, and legal hold systems connect to an ELM platform?

Identity connections govern who may see a matter, who may approve an invoice, and who is subject to a hold, and all three depend on the same underlying source of truth about your people.

Single sign-on is the baseline, and it should be non-negotiable. Enterprise credentials, federated through SAML 2.0 or OpenID Connect, mean a business user reaches the request portal without a second password and, more importantly, arrives already identified. Their division, region, cost center, and manager come along with them. The retailer program relied on exactly this: business users logged in through enterprise credentials and the system recognized their division and reporting line without asking. Every field a user does not type is a field that cannot be wrong.

The HR system of record extends that from authentication to structure. Approval chains follow the org hierarchy, so an invoice above a threshold routes to the right manager without an administrator maintaining a routing table. When someone changes roles, their access follows. When someone leaves, their matters reassign rather than orphan.

Note: There are still e-billing systems that need physically fixed defined routing processes. While it may be prescribed for certain situations, modern design requires honoring a flexible system that adapts with the enterprise. If every re-org means design change to your approval routes, then it means lot of work for the team maintaining the system. You only realize the architectural limitations when actually configuring the system. Connect with me or my colleagues at Swiftwater during the software diligence phase.

Legal hold is where identity turns into obligation. When litigation is reasonably anticipated, the department must identify custodians, issue holds, track acknowledgments, and defend the process later. Identifying the right custodians depends on knowing who worked where, on what, and when, which is an HR question before it is a legal one. EDRM’s Identification Guide is explicit that locating potentially discoverable data across business units, people, and IT systems is what makes a subsequent hold effective. A hold module fed by a live HR feed can name custodians by department, role, and tenure. In contrast, a hold module fed by a manual upload can name whoever was on last quarter’s list.

The same identity backbone carries the adjacent compliance workloads that legal departments increasingly own: third-party risk assessments, ethics hotline intake, background screening, and I-9 records. Each of these is a workflow with a person at the center and an obligation attached. Each becomes materially cheaper to run when the person is already known to the system. The matter record is the natural home for the resulting work, as covered in Transform Legal Operations: Matter Management within ELM Systems.

What to ask a vendor about identity and obligation: Do you support SAML 2.0 and OpenID Connect natively, or through a third-party broker? Does user provisioning happen automatically from the HR system, or does an administrator create accounts? Do approval thresholds and routing read the live org hierarchy? When an employee changes department, does their access change without a ticket? For legal hold, can custodians be identified by HR attributes rather than by name, and does the custodian list refresh as the hold runs? If hold is handled by a separate platform, does the ELM matter record show hold status, and does releasing the hold write back?

Where should documents live when the ELM has its own document features?

Documents should live in whichever system is designated the system of record, and the danger is that most ELM platforms make that decision easy to avoid.

Nearly every ELM ships lightweight document storage. Upload, version, tag, retrieve. That capability is adequate when documents are matter artifacts to be filed and found again: an engagement letter, a court filing, a signed agreement, a memo. It becomes inadequate when the department drafts heavily, versions collaboratively, needs full-text search across twenty years of work product, or applies retention schedules that vary by matter type and jurisdiction.

Three architectures are defensible, and the choice should be made explicitly.

ELM as system of record. Documents live in the ELM, attached to matters and contracts. Simplest to govern, easiest to report on, and adequate for departments whose document volume is moderate and whose drafting happens elsewhere before the final version arrives. The limitation is customization depth. If your retention rules or metadata model are unusual, you will hit the platform’s ceiling.

A legal document management system as system of record. NetDocuments or iManage holds documents; the ELM holds matters and links to them. Correct for departments with heavy drafting workflows, sophisticated retention obligations, or lawyers who came from firms and expect firm-grade document handling. The connection has to be bidirectional: creating a matter should create its document workspace, and the document system should know which matter a document belongs to without anyone typing a number.

An enterprise store as system of record. SharePoint or Box holds documents under enterprise governance; the ELM links out. Cheapest, and defensible when IT mandates it. The cost is that legal metadata and enterprise metadata rarely agree, and someone has to reconcile them.

The customization question is where these architectures separate, and it is the question buyers actually ask. How far can the metadata model bend before the platform requires custom development? Can retention schedules vary by matter type, jurisdiction, and contract counterparty simultaneously? Can a document template pull matter data, contract data, and party data into a generated draft?

A platform whose document features are configurable through the administrative interface will serve a demanding department for years. While some of the technological capabilities may have changed I wrote the following articles showing how legal systems can have overlapping functionalities and this is something a legal function needs to decide before they buy or implement a system. Here is my article for the Association of Corporate Counsel (ACC), Document Management, Contract Management, Records Management, and Knowledge Management Systems: What Are They, What Do they Do, and What are the Differences?

What to ask a vendor about documents: If we designate NetDocuments or iManage as the system of record, does matter creation provision the workspace automatically? Does document metadata sync in both directions, or does the ELM only display a link? Can retention schedules be configured by matter type, jurisdiction, and entity without custom development? What is the full-text search scope, and does it reach documents held in the connected system or only in the ELM? Which document configuration changes require professional services, and which can an administrator make?

How does e-signature fit into an ELM implementation?

E-signature belongs to matter activity that requires acceptance of terms and documents – ranging from approvals, policies, contracts, attestations, acceptances, etc.

The forward direction is easy and every vendor has it. A contract reaches final form, someone sends it to DocuSign, Adobe Sign, or PandaDoc, and the parties sign. The backward direction is where implementations quietly fail. The executed copy sits in the signature platform. Someone downloads it. Someone uploads it to the repository, sometimes. The execution date lives in a confirmation email. The obligations inside the contract have no start date because nothing recorded when the contract started.

A real connection sends the signature request from the matter document record, tracks status on that record while it is out for signature, and writes the executed artifact, the execution date, and the signatory identities back to that same record on completion.

In the retailer program, Swiftwater implemented, contracts routed to DocuSign for execution and returned into the contract repository, and the obligations application picked them up from there. Obligation monitoring worked because execution wrote back. Where execution does not write back, obligation monitoring tends to be a spreadsheet with a reminder date columns on it.

This is also where the self-service path proves itself. A standard agreement that a business requester completes without legal involvement should reach execution, file itself in the repository, and register its obligations without a lawyer touching it at any point. Every manual step you leave in that chain is a step that will be skipped under deadline, and the contract that skipped it will surface two years later when someone asks whether the renewal notice went out.

What to ask a vendor about execution: Is the e-signature connection native or built on a generic API? Does execution status appear on the contract record while signature is pending? On completion, does the signed artifact, the execution date, and the signatory list write back automatically? Does the obligation monitoring clock start from the written-back execution date? Can a self-service contract reach execution and filing with no legal user in the chain?

What determines whether an ELM integration is real or nominal?

Five questions separate a connection that works from a connection that appears on a slide. Every vendor will answer yes to “do you integrate with SAP.” These are the questions that produce different answers from different vendors.

1. Direction. Does data move one way or both ways? A read-only feed from the HR system is a real connection. A read-only feed to accounts payable is a report. Name the direction for every connection in your architecture, and be suspicious of any diagram drawn with lines instead of arrows.
2. Write-back. When the receiving system acts, does the originating record learn about it? The invoice is paid; does the matter know? The contract is signed; does the obligation clock start? The hold is released; does the matter status change? Write-back is the single most reliable discriminator between a platform that is a system of record and a platform that is a filing destination, and it is the question most often left unasked during selection.
3. Timing. Is the exchange event-driven or batched? An accrual that reaches the general ledger nightly is fine. An approved invoice that reaches accounts payable nightly is fine. A custodian list that refreshes monthly during active litigation is a problem. Match the timing to the obligation, and make the vendor tell you which connections are event-driven and which are scheduled, because the demo will not distinguish them.
4. Build. Is this a maintained native connector, a listed marketplace app, or custom API work built once for your tenant? A native connector is maintained by the vendor and survives their upgrades. Custom API work is maintained by whoever built it, which after go-live is frequently nobody. Ask which of the connections in your architecture are which, and ask to see the API documentation before you sign rather than after.
5. Ownership. Who owns the connection after go-live, and who funds it? When the AP system upgrades, who fixes the connection and out of whose budget? When the connector breaks on a Friday, who is called? First-time implementations in this category fall short of expectations often enough that the pattern is familiar to anyone who has run two of them, and unowned connections recur among the reasons. This is a contractual question, and it belongs in the statement of work.

The pattern to watch for is a connection that reads one way, on a batch schedule, through custom code that nobody owns. It will demo perfectly and it will decay within eighteen months. The evaluation discipline that surrounds these questions is laid out in ELM Software: Buyer’s Guide for Legal Departments, and the question of who is qualified to build and maintain these connections is covered in this guide that can be applied to an Onit or any other platform implementation -> Onit Implementation Partner: How to Evaluate One.

How should legal departments sequence these connections during a rollout?

Sequence by dependency, because a connection built before the thing it connects to has nothing to carry.

The order that works can generally follows the tiers. Work has to arrive before it can be managed, so the request portal and its identity connection come first. Matters have to exist before invoices can be billed against them, so matter management follows. eBilling follows matter management. Contract lifecycle management usually comes last, because it depends on identity, matter, and document connections that should already be running.

For example, this was the sequence in the retailer implementation that Swiftwater completed: the legal service request portal first, then matter management, then eBilling, and contract lifecycle management delivered last. Each phase inherited a working identity connection and a populated matter record from the phase before it. Nothing was built twice.

Two things have to be true before you connect anything. The data you are about to move has to be worth moving, which is the subject of ELM Data Migration: How Legal Departments Should Approach It. And the people on both ends of each connection have to change how they work, which is the subject of Legal Technology Change Management: Why It Matters. A connection nobody uses is indistinguishable from a connection that does not exist.

The phased implementation timeline itself, along with the failure modes that recur across programs, is covered separately in ELM Implementation: What It Requires for Success. This article is about what has to connect. That one is about how to get there without stalling in phase two.

Bottom Line

An ELM platform stores what you provide it. The connections determine what you send it, and whether anyone downstream can act on it.

Work that arrives through a portal becomes a matter.

An invoice that reaches accounts payable becomes spend under management.

A contract that writes its execution date back to its record starts its obligation clock.

Before you compare feature grids, name every system that has to feed the ELM and every system that has to receive from it, then ask the five questions of each connection.

Evaluate the connections before you evaluate the platform, because the platform will be exactly as valuable as the systems on either side of it.

---

This is the work Swiftwater does in legal technology programs. We map where legal work originates across the business, name the system of record at each tier, specify the connections that carry data in both directions, and sequence the build so that each phase inherits working connections from the one before it. If you are selecting or rebuilding an ELM platform and want the architecture resolved before the vendor decision, our legal technology consulting and solutions practice is built for exactly that problem.

---

Frequently Asked Questions

What systems should an ELM platform integrate with? Four groups, in order of what each one unlocks. Intake systems bring work in, including the legal service request portal and upstream business systems in sales, procurement, real estate, and HR. Finance systems close the legal spend loop, carrying approved invoices out to accounts payable and accruals back in. Identity and obligation systems govern who may act, including single sign-on, the HR system of record, and legal hold. Document systems hold what the work produces, meaning the document repository and the e-signature platform. Each tier depends on the one above it.

What is the difference between a real ELM integration and a nominal one? Five questions separate them. Which direction does data move, one way or both. Does the receiving system write back to the ELM record, or only read from it. Is the exchange event-driven or a scheduled batch. Is it a maintained native connector or custom API work built once for your tenant. And who owns and funds the connection after go-live. A nominal integration usually reads one way, on a batch schedule, through custom code that nobody owns two years later.

Should documents live in the ELM system or a separate document management system? It depends on what the documents are for. Most ELM platforms ship lightweight document storage that is adequate when documents are matter artifacts to be filed and retrieved. If your department drafts heavily, versions collaboratively, and needs full-text search across decades of work product, a dedicated legal document management system should hold the documents while the ELM holds the matter record and links to them. The decision that matters is naming one system of record and having every other system point at it.

How does e-signature integrate with an ELM or CLM system? The signature request should launch from the contract or matter record, and completion should write back to that same record automatically. A weak integration sends the document to the signature platform and leaves the executed copy stranded there, requiring someone to download it and re-upload it. Ask a vendor whether execution status, the signed artifact, and the execution date all return to the originating record without manual handling, and whether the obligations extracted from that contract begin their monitoring clock on that date.

In what order should a legal department connect its ELM systems? Start where work enters. A legal service request portal establishes intake and workload management before anything downstream exists to receive that work. Matter management follows, giving triaged requests somewhere to live. eBilling follows matter management, because an invoice needs a matter to bill against. Contract lifecycle management usually comes last, since it depends on identity, matter, and document connections already being in place. Sequencing by dependency rather than by urgency prevents building connections that have nothing to connect to.

---