Managing Regional VAT Tables in Legal eBilling

VAT tables are the configured records in an eBilling platform that tell it which tax authorities, tax codes, and rates apply to an invoice, so the tax a law firm charges can be checked against what it should be. In a legal department receiving invoices from several countries, they decide whether a 20 percent charge from a London firm and a 19 percent charge from a Frankfurt firm both pass review, and which general ledger account each one lands in.

What are VAT tables in legal eBilling?

VAT tables in legal eBilling are the set of tax authority and tax code records an ELM platform uses to match the tax on each invoice to an approved code and rate. In Onit Unity, Onit’s AI-native ELM platform, the Tax Authorities menu becomes available once VAT functionality is enabled for the environment, and each tax code carries its rate, a GL tax account, optional splits, and effective and expiration dates.

The structure has three layers:

• Tax authorities. One record per country or jurisdiction, carrying the authority code, whether the country is in the EU, and an active or inactive status.
• Tax codes. The rates themselves, each with a description, code, percentage, and the tax account it posts to.
• Relationships. Links from each tax authority to your billing legal entities and to the vendors who bill them.

How does an ELM platform decide which VAT applies to an invoice?

An ELM platform decides which VAT applies to an invoice by pairing where the invoice comes from with the entity it is billed to. Once tax authorities and codes are configured, Unity matches the tax amounts on an incoming invoice to the applicable tax code and rate.

That makes the jurisdiction pairing the heart of the setup. A Paris firm billing your French entity raises a different question from the same firm billing your US parent, and a firm with offices in four countries may bill your entity from any of them. Your tax team decides the treatment for each pairing, and the platform applies it consistently.

Treatments such as reverse charge, zero rating, and place-of-supply rules depend on your configuration and your tax advice. Confirm each one with your tax team before go-live, because the platform enforces exactly what you configure.

What goes into a tax authority record?

A tax authority record holds the identity and status of one taxing jurisdiction, and every other tax setting hangs off it. Getting these records right first saves rework across vendors, entities, and codes.

• Country and authority code. A consistent naming scheme (for example, the two-letter ISO country code) keeps imports and reports readable across 10 or 20 jurisdictions.
• EU indicator. Marking whether the country is an EU member drives how cross-border EU invoices are treated in your configuration.
• Active status. Only active authorities can be selected for invoicing, so retired or unused jurisdictions stay in the history without appearing in drop-downs.

Most departments start with 5 to 15 authorities, covering countries with a billing entity or a panel firm.

What does a tax code need to hold?

A tax code needs to hold the description, the code, the tax rate, and the tax account, plus any code split or rate split the jurisdiction requires. The rate drives validation, and the tax account decides where the tax posts in your general ledger.

• Rate. The percentage for that code, such as 20 percent for UK standard-rated services. One authority usually needs several codes, for example a standard rate, a reduced rate, and a zero rate.
• Tax account. The GL account the tax amount maps to. Agree these with finance before configuration, since a wrong account reconciles badly for months.
• Splits. Code splits and rate splits handle jurisdictions where one invoice line carries more than one tax component.

Name codes so reviewers can read them: “UK-STD-20” beats “TC014” in an exception queue.

How should vendors and legal entities be mapped to tax authorities?

Vendors and legal entities should be mapped to tax authorities so that every invoice arrives with a clear jurisdictional context. In Unity, the tax authority on a vendor record says where the invoice comes from, and the tax authority on a legal entity says who the vendor is billing.

• Entity mapping. Link each billing legal entity to the authority it is registered with, as part of wider legal entity mapping. A department with eight entities across five countries should be able to list every pairing on one page.
• Vendor mapping. Link each firm to the tax authority it bills from. Only active authorities are used for invoicing, so set up the authority record before loading the firms that bill from it.
• Multi-office firms. Large firms billing from several offices may need one vendor record per billing office, each mapped to its own authority.

Build the vendor mapping into firm onboarding, so tax data is collected once.

How do law firms submit VAT on LEDES invoices?

Tax authorities check closely, since EU member states missed an estimated €89 billion in VAT revenue in 2022, about 7 percent of what was due.

Law firms submit VAT on LEDES invoices as tax lines with the rate written as a decimal, so 0.05 represents 5 percent and 0.20 represents 20 percent. The international LEDES formats carry tax fields that the US-only 1998B format lacks, which is why global e-billing VAT compliance depends on firms submitting LEDES 1998BI.

• Decimal rates. A firm that sends “20” where the platform expects “0.20” produces a mismatch on every line. Put the format in the billing guidelines with a worked example.
• Multiple rates in one country. Vendors submitting invoices with several VAT rates for the same country can combine their taxes into a single line item. Decide whether you accept that, and document it.
• Taxable base. The tax should be calculable from the base. A fee base of EUR 10,000 at 20 percent should show EUR 2,000 of VAT, and a reviewer should be able to check that in seconds.

What should happen when invoice VAT does not match the table?

When invoice VAT does not match the table, the mismatch should be classified by cause and routed to someone who can resolve that cause. Whether a mismatch produces a warning, an error, or a rejection is a configuration decision, so make it deliberately for each type.

• Missing or inactive authority. The vendor or entity points at a jurisdiction the table lacks or has retired. Usually a setup fix, owned by eBilling administration.
• Rate mismatch. The firm charged a rate the table does not hold for that pairing. Return it to the firm, or route it to tax review if the rate may have changed.
• Calculation mismatch. The rate is valid but the tax amount does not equal base times rate within an agreed tolerance, often 0.01 per line.
• Account mismatch. The tax maps to the wrong GL account. Finance should see these.

Track overrides by jurisdiction, vendor, and reviewer. A firm generating repeat rate mismatches every month needs a call.

How should VAT rate changes be managed?

VAT rate changes should be managed through a documented change process, because the platform validates against the rates you configure and someone has to keep them current. Somebody in your department owns the table, and the platform holds whatever that person enters.

Assign one owner for the table and one approver from tax or finance. Review every active rate at least once a year and whenever a country announces a change, which governments typically do 30 to 90 days ahead. Add a new code with an effective date for the new rate and give the old code an expiration date, so invoices for earlier work still validate against the rate in force at the time. Record the source, effective date, approver, and prior value for every change.

How do you test VAT tables before go-live?

You test VAT tables before go-live by running real past invoices from every active jurisdiction through the configured platform and checking each tax result by hand. Twenty to forty invoices usually cover the cases that break.

Cover one invoice per entity and authority pairing, plus a multi-rate invoice, a zero-rated invoice, a credit note, and a firm that sends rates as whole numbers. Confirm the code matched, the expected tax, the exception raised on bad lines, and the GL account in the export. Repeat the key checks after promotion to production. Finally, trace a few invoices into the ERP to prove tax amounts and accounts arrive correctly.

Conclusion

VAT tables turn your tax team’s decisions into rules an eBilling platform can apply to every invoice. Build them in order (authorities, codes, then entity and vendor mappings), fix the LEDES rate format in your billing guidelines, decide how each type of mismatch is handled, and give the table an owner who manages rate changes on a schedule. Test every jurisdiction against hand calculations before go-live, and the tax on your legal invoices becomes something finance can reconcile without a spreadsheet.

Frequently asked questions

What are VAT tables in legal eBilling?

VAT tables are the tax authority and tax code records an eBilling platform uses to match the tax on each invoice to an approved code and rate. They also map each tax amount to the correct general ledger account.

Who updates VAT rates in an eBilling platform?

VAT rates in an eBilling platform are updated by the table owner your department assigns, because the platform validates against the codes and rates you configure. Add a new code with an effective date whenever a country changes its rates.

How do law firms show the VAT rate on a LEDES invoice?

Law firms show the VAT rate on a LEDES invoice as a decimal value. For example, 0.05 represents 5 percent and 0.20 represents 20 percent.

Why must vendors be mapped to a tax authority?

Vendors must be mapped to a tax authority so the platform knows which jurisdiction’s codes and rates to apply. The vendor’s authority shows where the invoice comes from, and the legal entity’s authority shows who is being billed.

What happens when a tax authority is set to inactive?

An inactive tax authority stays in the system for historical records and stops being available for new invoicing. This lets you retire a jurisdiction without losing its history.

How many invoices should be used to test VAT configuration?

Twenty to forty past invoices usually cover the cases that break. Include every entity and authority pairing, a multi-rate invoice, a zero-rated invoice, and a credit note.

---

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