Vendor ID mapping is the practice of keeping one logical record for each law firm in your ELM and linking it to the separate vendor ID that firm holds in every ERP your company pays from. A firm billing three subsidiaries can be vendor 100457 in SAP, supplier 88213 in Oracle, and an internal ID in NetSuite, all at once. The ELM approves the invoice. The mapping decides which ERP pays it and under which vendor record. When it is patched together in spreadsheets, invoices bounce between legal and AP, and spend reports count one firm as three.
What is vendor ID mapping in a multi-ERP legal environment?
Vendor ID mapping in a multi-ERP legal environment is a cross-reference that translates one ELM vendor into the correct local vendor ID for each ERP and legal entity. It sits between the ELM and finance, usually in middleware or a dedicated table the integration reads before every invoice export.
Legal works at the firm level and finance works at the entity level, with a separate vendor master in each ledger. The mapping is the piece that turns “approved invoice from Firm A on Matter 2026-0142” into “post to company code 3100, vendor 100457.”
Why does one law firm end up with several vendor IDs?
One law firm ends up with several vendor IDs because each ERP and legal entity maintains its own vendor master, and the firm was set up separately in each.
- Separate ERP instances. Companies that grew by acquisition often run two to five ERPs, and each subsidiary created the firm when it first needed to pay it.
- Local tax and banking. A global firm bills a UK entity from its London office and a US entity from New York, with different tax registrations, currencies, and bank accounts on each record.
- Historic duplicates. A firm renamed after a merger, or entered twice with slightly different spelling, leaves two active records inside the same ERP.
Each record is valid for the entity that pays it. The ELM simply has to know which one to use.
How should a vendor cross-reference table be structured?
A vendor cross-reference table should hold one row per firm, per ERP, per legal entity, keyed to a stable global ID that never changes once assigned.
- Global vendor ID. The ELM’s own identifier for the firm, ideally anchored to a tax ID or another external identifier so new records can be matched automatically.
- ERP instance and company code. Which ERP and which legal entity the row applies to, for example SAP company code 3100 or a named Oracle operating unit.
- Local vendor ID. The vendor number in that ERP, such as the SAP LIFNR value, together with the remit-to site where the ERP uses one.
- Status and effective dates. Active or blocked, with start and end dates, so a retired record stays in history and stops receiving new invoices.
Keep superseded IDs in the table with an end date. Deleting them breaks the audit trail for invoices that already posted. A department with 150 active firms across four entities typically lands somewhere between 250 and 400 mapping rows.
Which system should own law firm vendor IDs across ERPs?
Finance should own law firm vendor IDs across ERPs, through the ERP vendor masters or a master data hub, and the ELM should subscribe to them.
- ERP or master data hub. This is the system of record for legal names, tax IDs, and banking. Changes are made here once and flow outward in one direction.
- ELM. The ELM receives the mapped IDs and uses them for routing. Legal operations does not create or edit ERP vendor numbers inside it.
- Legal operations. Your team owns what sits on top of the vendor: rates, timekeepers, billing guideline assignments, and which firms are approved for which matter types.
Agree this split in writing before the build, because each field in an ELM finance integration needs exactly one owning system.
How does the legal entity on a matter route invoices to the right ERP?
The legal entity on a matter routes invoices to the right ERP because each entity belongs to exactly one ERP instance and company code. When an invoice is approved, the integration reads the matter’s legal entity, looks up the ERP that entity posts to, and then finds the firm’s vendor ID for that ERP and entity in the cross-reference.
This makes the legal entity field on the matter the most important routing input in the whole design, and the reason legal entity mapping has to be settled first. It should be mandatory at matter creation and locked once invoices have posted. Matters that change entity after a restructuring should route invoices by service date. Split-billed invoices that allocate across two or three entities produce one ERP posting per entity, each with its own vendor ID.
What should pre-dispatch validation check before a legal invoice leaves the ELM?
Pre-dispatch validation should run six checks on every approved legal invoice before it leaves the ELM, so mapping errors are caught where legal operations can fix them.
- Entity resolves. The matter’s legal entity is active and maps to exactly one ERP instance and company code.
- Mapping exists. The firm has an active cross-reference row for that ERP and entity.
- Vendor is open. The local vendor ID is not blocked for posting or payment in the target ERP.
- Currency fits. The invoice currency is accepted on that vendor record or has an approved currency conversion rule.
- Tax data present. The tax registration on the vendor record suits the entity being billed.
- No duplicate. The firm’s invoice number has not already posted against the same vendor in that ERP.
An invoice that fails any check stays in the ELM with a readable reason attached.
How should vendor ID mapping exceptions be managed?
Vendor ID mapping exceptions should be managed through one named queue with a clear owner and a turnaround target for each exception type.
- Missing mapping. A firm bills an entity for the first time. Legal operations requests the vendor setup from finance, and the target is two to three business days.
- Blocked vendor. The ERP record has been blocked, often for expired tax forms or a bank change. Finance resolves it, and legal tells the firm the invoice is held.
- Ambiguous match. Two active vendor IDs exist for the same firm and entity. Finance decides which survives and blocks the other.
Track the exception rate monthly. A mature setup usually holds mapping exceptions to 1 to 2 percent of invoice volume, with spikes only when a new entity or a batch of new firms comes on board. Each exception costs money, and a 2026 benchmark survey put the average cost to process one invoice at $9.90, against $2.67 for the best-performing teams. Most of those spikes trace back to firm setup, so tie mapping to firm onboarding.
How do you build the vendor mapping for a new ELM rollout?
You build the vendor mapping for a new ELM rollout by exporting each ERP’s vendor master, matching records to your firm list, and having finance confirm every match before load. Start with active vendors in the legal services categories, usually filtered to firms paid in the last 24 months. Match first on tax ID, then on normalized legal name and address, and route anything uncertain to a human reviewer.
In the US, finance teams can confirm the tax IDs themselves, since the IRS TIN Matching service lets payers validate name and TIN combinations before filing information returns. In practice, tax ID matching resolves most records automatically, and the remaining 10 to 20 percent need manual review because of missing tax IDs, trading names, or merged firms. Allow two to four weeks for that review on a program with several hundred firms.
How do you keep vendor mappings accurate after go-live?
You keep vendor mappings accurate after go-live by treating every vendor change in an ERP as an event the ELM must receive. A nightly sync of changed vendors catches mergers, bank changes, and retired records within a day.
Add two routine controls. A monthly report of firms invoicing without an active mapping shows gaps before they block a payment run. A quarterly review with finance retires unused rows and confirms that no firm holds two active IDs in the same entity.
Conclusion
Vendor ID mapping works when finance owns the vendor records, the ELM owns the matter’s legal entity, and a governed cross-reference connects the two. Get the table structure and ownership right before the build, validate every invoice before it leaves the ELM, and give exceptions a named owner. Spend reporting then sees each firm as one firm, however many ERPs pay it.
How Basla can help
Basla provides delivery teams for enterprise legal management and eBilling software implementation, covering legal technology consulting, business analysis, vendor and entity data mapping, integration specifications, validation and exception design, testing with finance and AP, documentation, and hypercare after go-live. Basla teams have delivered matter management and eBilling programs across more than 10 global jurisdictions.
Frequently asked questions
What is vendor ID mapping for legal departments?
Vendor ID mapping for legal departments links each law firm in the ELM to the vendor ID that firm holds in every ERP and legal entity that pays it. The ELM then uses the matter’s legal entity to send each approved invoice to the right ERP under the right vendor record.
Who should maintain the vendor cross-reference table?
Finance should maintain the vendor records behind the cross-reference table, in the ERPs or a master data hub. Legal operations requests new mappings when a firm bills a new entity and owns the firm-level data in the ELM, such as rates and timekeepers.
How many vendor IDs can one law firm have?
One law firm can have one vendor ID for each ERP and legal entity that pays it, and global firms often hold five or more. The cross-reference ties them back to one firm in the ELM.
What happens when a law firm has no mapping for an entity?
When a law firm has no mapping for an entity, pre-dispatch validation holds the invoice in the ELM and places it in an exception queue. Legal operations requests the vendor setup from finance, and the invoice is released once the new mapping is active.
Should vendor matching rely on tax IDs or firm names?
Vendor matching should rely on tax IDs first and use normalized firm names and addresses as a fallback. Tax IDs resolve most records automatically, and name-based matches should always go to a human reviewer before load.
How long does it take to build a vendor mapping for an ELM rollout?
Building a vendor mapping for an ELM rollout usually takes three to six weeks for a department with several hundred firms. Most of that time goes to manual review of unmatched records.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*