Vendor Master Data: Office-Level Site Mapping for Law Firms

Your largest firm bills from six offices, and your ERP pays each through a different site. How office-level site mapping keeps one master vendor per firm, with the AP details that route each payment correctly.

Vendor master data is the set of records that defines who your legal department pays: each law firm, its offices, its timekeepers, and the accounting identifiers your finance systems use to send money. Office-level site mapping is the design choice that keeps one master record per firm while recording each billing office, with its own address, tax details, and AP site ID, as a child record underneath it.

On an ELM build, this is one of the first data design decisions and one of the hardest to reverse. Get it right and spend, discounts, and scorecards roll up cleanly to the firm while every invoice reaches the right ERP site. Get it wrong and the same firm appears five times in your reporting, or payments land against the wrong remittance account.

What is office-level site mapping in an ELM build?

Office-level site mapping in an ELM build is the practice of linking each law firm’s billing offices to a single parent vendor record as child office records. Each office record holds the location details finance needs, and every invoice, timekeeper, and dollar still belongs to the parent firm.

“Which firm did the work?” is answered by the parent vendor. “Which office billed it, and where should payment go?” is answered by the office record. Firm-level reporting reads the parent, and accounts payable reads the office.

This structure sits at the center of the wider data model, so it belongs in the design phase alongside matters, budgets, and invoice rules.

Why should each law firm have one master vendor record?

Each law firm should have one master vendor record because every firm-level measure, from total spend to performance scores, depends on the firm’s activity landing in one place. Separate records for “Firm LLP Chicago” and “Firm LLP Boston” split the relationship in two.

Three things break when offices become separate vendors:

  • Consolidated spend. Total fees per firm understate the relationship, and your top-firms report ranks one firm as three mid-sized ones.
  • Volume discounts. Tiered discounts based on cumulative annual spend never reach the next tier, because each office record accumulates separately.
  • Performance scores. Matter-close evaluations divide across records, so no single score reflects the whole relationship.

In the US, the IRS TIN Matching service lets payers validate name and TIN combinations before filing information returns, which makes the tax ID a reliable key. Enforce the rule at onboarding with a duplicate check on firm name and tax ID, the same control that keeps vendor classification to one category per firm, and apply it to bulk imports. A firm with 12 offices should produce 1 vendor record and 12 office records.

Some platforms, Onit Unity among them, hold one address and one currency on each vendor record, so a firm billing from offices in two currencies is set up as two vendor records. There, a vendor group or naming convention does the roll-up to the firm.

What belongs on each law firm office record?

Each law firm office record should hold the location-specific data that finance, tax, and correspondence depend on, and nothing that belongs at the firm level. Rate cards and firm-wide agreements stay on the parent.

The four fields that matter most:

  • Street address. The billing location, used for jurisdiction and remittance correspondence.
  • Tax registration. VAT, GST, or state tax registration numbers that apply to invoices from that office.
  • Office contacts. The billing contact who answers invoice queries for that location.
  • AP site ID. The site code your ERP uses to route payment to the office’s remittance details.

How is an AP site ID different from an ERP vendor ID?

An AP site ID identifies where a payment goes, and an ERP vendor ID identifies which vendor account in a given finance system receives it. One describes a location, and the other describes a system record.

A global firm can have one vendor ID in a US finance system and another in a UK finance system, and each of those accounts can hold several sites. Mapping both correctly means storing the site ID on the office record and the system-specific vendor ID on a separate record linked to the parent vendor, keyed by finance system.

Mixing them is a frequent design error: invoices from one office post against the wrong account, and nobody notices until the firm chases a late payment. Bad master data also invites fraud, and business email compromise caused close to $2.8 billion in losses reported to the FBI in 2024, often through fake changes to bank details. Integrating ELM with finance and ERP systems means agreeing which record holds each identifier before the first test invoice moves.

Why should timekeepers be linked to a law firm office?

Timekeepers should be linked to both the parent firm and a specific office so rate validation, tax treatment, and payment routing all use the correct location. The link is set once in setup and reused on every invoice.

Each link does a distinct job:

  • Rate validation. Submitted rates are compared against the approved rate for that timekeeper, which can differ by office and currency.
  • Tax treatment. The office determines which tax registration and tax rules apply to that timekeeper’s fees.
  • Payment routing. The office on the invoice carries through to the AP site used for payment.

When a timekeeper moves offices, update the link with an effective date. Overwriting it in place changes how historic invoices appear in reporting.

How does the billing office flow from invoice to payment?

The billing office flows from invoice to payment by following the office record from LEDES submission through approval to the outbound AP export. Each step either confirms or carries forward the office the invoice came from.

The sequence on a typical build:

  • Submission. The firm submits a LEDES invoice, and validation checks each timekeeper and rate against the office profile.
  • Review and approval. The invoice displays the billing office, so reviewers and approvers see which location they are paying.
  • AP export. The approved invoice is sent to finance with the vendor name, billing office, site ID, amounts, and tax, the data that later builds the outbound AP payment file.
  • Status update. The invoice moves to a pending payment status, with the send date recorded in its history.

The export should also carry the invoice PDF, supporting receipts, and a GL allocation that balances to 100 percent.

How do you clean up duplicate office vendors before migration?

You clean up duplicate office vendors before migration by grouping legacy records by firm, choosing one surviving parent, and converting the others into office records. The cleanup has to finish before invoices and matters are migrated, because history follows whichever record survives.

Start with an export of every active vendor, its tax ID, and its last 24 months of spend. Group by tax ID and normalized firm name, then review each group with finance, because some apparent duplicates are genuinely separate legal entities with their own tax registrations. Map each retired record’s site codes and contacts onto the new office records.

Plan two to four weeks for a vendor list of a few thousand records. Duplicate firm records are among the first problems a migration exposes.

How do you test office-level site mapping before go-live?

You test office-level site mapping by submitting invoices from every office pattern and confirming each one validates, routes, and exports with the right identifiers. For a panel of 30 firms that is typically 40 to 60 test invoices.

Cover three groups of cases:

  • Office variations. A single-office firm, a multi-office firm in one country, and a firm billing from several countries and currencies.
  • Timekeeper moves. A timekeeper who changes office mid-year, with invoices before and after the effective date.
  • Finance system splits. Matters belonging to different legal entities, so the same firm is paid through two finance systems.

Check the outbound export against what finance expects, field by field, and run the full set again in each environment.

How should vendor master data be monitored after go-live?

Vendor master data should be monitored monthly after go-live, with a short report on duplicates, incomplete office records, and payment rejections from finance. Monthly checks catch drift before it reaches quarter-end reporting.

Track the duplicate rate against a target of zero parent records sharing a tax ID, and the share of office records with a complete site ID, address, and tax registration, with a target of 100 percent. Any payment rejected by finance for a site or vendor mismatch should be traced back to the office record and corrected at the source. Review the full list of offices for your top 10 to 15 firms once a year, since firms open, close, and merge offices more often than they tell you.

Conclusion

Vendor master data decides whether your firm-level reporting and your regional payments can both be right at the same time. Office-level site mapping gives you that: one parent record per firm, child office records with their own AP site IDs, and timekeepers linked to the office they bill from. Clean the legacy list before migration, test every office pattern, and check the records monthly once you are live.

How Basla can help

Basla provides delivery teams for enterprise legal management and eBilling software implementation, covering legal technology consulting, business analysis, vendor and office data model design, finance and AP integration requirements, legacy vendor cleanup, testing, documentation, and post-go-live support. Basla business analysts map your firms, offices, and finance systems into a structure the platform can enforce, and the QA team proves each office pattern from invoice to export before launch.

Basla has delivered matter management and eBilling programs across more than 10 global jurisdictions, and can scale the delivery bench when timelines compress.

Frequently asked questions

What is vendor master data in an ELM platform?

Vendor master data in an ELM platform is the set of records defining each law firm, its offices, its timekeepers, and its finance system identifiers. It drives invoice validation, spend reporting, and payment routing.

What is office-level site mapping?

Office-level site mapping links each law firm’s billing offices to one parent vendor record as child office records.

Should each law firm office be a separate vendor?

Each law firm office should be a child office record under one parent vendor. Separate vendors split spend, volume discounts, and performance scores across several records.

What is an AP site ID?

An AP site ID is the code a finance system uses to identify where a vendor payment is sent. It is stored on the office record so each billing office is paid correctly.

How is an AP site ID different from an ERP vendor ID?

An AP site ID identifies a payment location, while an ERP vendor ID identifies the vendor account in a specific finance system. A firm can hold different vendor IDs in different systems, each with several sites.

Why should timekeepers be linked to an office?

Timekeepers should be linked to an office so rate validation, tax treatment, and payment routing use the right location. The link should carry an effective date when a timekeeper moves.


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