Pricing
Supplier Verification · Live

Every supplier verified. Company, HMRC, bank account.

OmniPATH checks Companies House, HMRC VAT records, bank modulus and Confirmation of Payee in one automated pass - before any supplier can receive a purchase order or a payment. No spreadsheets. No phone calls. No guesswork.

4
Verification layers
<5s
Check time
Zero
Manual intervention
Supplier Verification Verified
FS Foodservice Ltd
Co. 02447635 · VAT GB 524 8462 18
96%
Companies House active Match
HMRC registered GB Std
Bank details verified 3rd party
Confirmation of Payee Match
The four-layer pass

Four government and banking-scheme APIs. One automated check.

Every UK supplier passes through Companies House, HMRC VAT, bank modulus and Confirmation of Payee - sequentially, automatically, with full audit trail. Sub-five-second result.

4
Verification layers
Companies House · HMRC VAT · Bank modulus · Confirmation of Payee
<5s
Check time
All four layers run in a single automated pass
100%
Coverage
Every supplier verified before first PO or payment
Zero
Payment fraud surface
Bank account confirmed to match named payee before funds leave
The four layers

The checks your auditors expect.

Each layer is a real-time API call to a UK authority - Companies House for company status, HMRC for VAT registration, bank validation and Confirmation of Payee. Failures are stored as structured JSON, audit-tagged as fraud-relevant and surface immediately to your admin team.

Layer 01
AI Integration

Companies House

Direct integration with the official Companies House REST API. Confirms the company exists, is currently active, the name matches (normalised) and the registered office postcode aligns with the supplier address.

  • Company number exists in the register
  • Company status is active - not dissolved, struck off, or liquidated
  • Registered name matches (Ltd / Limited / case / whitespace normalised)
  • Registered-office postcode matches supplier address
  • Flags if registered office is in dispute
ch_not_found
ch_not_active
ch_name_mismatch
ch_postcode_mismatch
ch_address_in_dispute
Layer 02
AI Integration

HMRC VAT

Real-time lookup against HMRC's VAT registration register. Validates the VRN, then cross-references the registered business name and postcode. Skipped automatically if the supplier doesn't have a VAT number - non-VAT-registered suppliers are normal.

  • VRN exists and is currently valid at HMRC
  • Registered business name matches supplier name (normalised)
  • Registered postcode matches supplier address
  • Production + sandbox environments supported
  • Auto-refresh OAuth tokens - no manual maintenance
vat_not_found
vat_name_mismatch
vat_postcode_mismatch
vat_contact_error
Layer 03
AI Integration

Bank Modulus

Sort code and account number passed through the UK Payments Association modulus check - the same algorithm a bank runs at the start of any faster-payments transaction. Confirms the account number is mathematically valid for that sort code and returns the bank and branch details.

  • Modulus check against official UK banking validation tables
  • Sort code resolved to bank, branch, address
  • Returns: bank name, branch title, address, town, postcode
  • Always runs - sort code and account number are required
  • Exponential-backoff retry on transient failures
bank_missing_details
bank_modulus_failed
bank_modulus_unavailable
Layer 04
AI Integration

Confirmation of Payee

The same name-check banks run before processing faster payments. Confirms the account holder name matches the bank's records for that sort code and account number - and detects switched accounts, non-existent accounts and opted-out banks. This is the layer that stops fraud before money moves.

  • Account holder name matches bank's records
  • Account type matches (personal vs business)
  • Detects switched accounts and non-existent accounts
  • Suggests corrected name on close match
  • Handles opted-out / not-enrolled banks gracefully
cop_no_match
cop_close_match
cop_account_does_not_exist
cop_account_switched
cop_unavailable
Companies House - Layer 01

Five checks. One government API.

Every newly-submitted supplier hits the same five checks against the official Companies House register. Failures land as structured JSON on the supplier record - code, message, field - auditable, exportable, defensible.

  • Company number exists and is active in the register
  • Status check - dissolved, liquidated and struck-off companies blocked
  • Name match - Ltd / Limited / case / whitespace normalised before comparison
  • Postcode match - registered office postcode against supplier address
  • Address dispute flag - surfaces Companies House disputes on the registered office
Companies House lookup
CH API · 1.2s
Company no.
03873787
Found
Status
active
Pass
Reg. name
FS Foodservice Ltd
Match
Reg. office
Buckingham · MK18 1HB
Match
In dispute
false
Clean
Incorporated
15 Oct 1999
-
HMRC VAT - Layer 02

VAT validated against HMRC's live register.

OmniPATH calls HMRC's VAT Check API directly - OAuth 2.0 client credentials, read:vat scope only. Token lifecycle managed automatically. The same lookup HMRC themselves run for VAT registration verification, just embedded in your supplier flow.

  • VRN lookup against HMRC's live VAT registration register
  • Registered name cross-referenced against supplier name
  • Registered postcode cross-referenced against supplier address
  • Skipped automatically for non-VAT-registered suppliers - no false negatives
  • Production and sandbox environments - full dev/test parity
HMRC VAT lookup
HMRC API · 1.4s
VRN
GB 824 1962 47
Valid
Reg. name
FS Foodservice Ltd
Match
Reg. postcode
MK18 1HB
Match
Scope
read:vat
OAuth 2.0
Last refresh
02 May 2026 14:24
Auto
Bank Modulus - Layer 03

The same maths your bank runs.

The modulus algorithm validates that a sort code and account number combination is mathematically valid before any payment instruction goes anywhere. Same check the banking system itself does at the moment of payment - pulled forward to the moment of supplier setup.

  • Official modulus tables - the UK banking validation algorithm
  • Sort code resolved to bank name, branch title, address, town, postcode
  • Always runs - sort code and account number are mandatory verification fields
  • Retry logic - exponential backoff with three attempts on transient failures
  • Catches typos before they reach the BACS file - saves the recall fee
Modulus check · validateaccount
Bank API · 0.6s
Sort code
30-99-50
Resolved
Account no.
12345678
Mod ✓
Bank
Lloyds Bank plc
Match
Branch
Aylesbury · HP19 7QH
-
Mod algorithm
DBLAL · standard
Pass
Layer 04 · The fraud-stopper

Confirmation of Payee. Eleven outcomes, one verdict.

The Confirmation of Payee scheme is the same name-check banks run before processing your faster-payment instructions. Every possible outcome surfaced - match, close match, no match, switched account, account doesn't exist - with the action your team should take.

Match
match
FS Foodservice Ltd

Account holder name and account type both match the bank's records exactly. Clean pass - payment can proceed.

Verified - proceed
Close match
close_match
Fresh Direct Ltd → "Fresh Direct Limited"

Near match. The bank suggests the registered account name is "Fresh Direct Limited" rather than "Fresh Direct Ltd". Most likely benign - Ltd vs Limited - but worth confirming before you send funds.

Review suggested name
No match
no_match
Joe's Kitchen Supplies

The account holder name does not match the bank's records. This is the classic fraud pattern - supplier identity stolen, bank details swapped. Do not pay. Verify with the supplier directly via a known-good phone number.

Blocked - do not pay
Account does not exist
account_does_not_exist
Metro Foods Ltd

Sort code passed modulus check, but the account number doesn't exist at that branch. Either a typo or a fabricated account. Either way - payment is blocked at the verification step, not at the BACS bounce two days later.

Blocked - check details
Account switched
account_switched
Quick Catering Ltd

The account has been switched to a new provider via the Current Account Switch Service. Old account is no longer the supplier's working account. Request the new bank details from the supplier before re-running verification.

Request new details
Type mismatch
close_match_type_mismatch
Acme Trading

Name is close, but the account type doesn't match - bank has it as personal, supplier set up as business (or vice versa). Often a sole-trader configuration issue. Confirm with the supplier before paying.

Check account type
Bonus layers

Duplicate detection. Pre-flight validation.

Two checks that run before - and around - the four core layers. Stop duplicate suppliers from sneaking in and stop verification from kicking off when required fields are obviously missing.

Bonus
Within-org check

Duplicate detection

Before verification runs, OmniPATH checks the supplier's company number and email against every other supplier in your organisation. Catches the same vendor entered twice with slightly different spellings - the silent data-quality killer.

  • Match by company number - within your organisation only
  • Match by email - within your organisation only
  • Returns the existing supplier name, not just "duplicate detected"
  • Runs on bulk import too - duplicates skipped with a per-row reason
dup_company_no_match
dup_email_match
Pre-flight
Field validation

Required-field check

If verification kicks off without the data it needs, you don't burn an API call to find out - you get a clear "this field is missing" error. The supplier is told exactly what's needed before the four layers run.

  • Company number required for Companies House lookup
  • Company name and address required for cross-reference
  • Sort code and account number required for bank checks
  • VAT number - optional; layer 02 skipped cleanly if absent
ch_missing_company_no
ch_missing_name
ch_missing_address
bank_missing_details
Procurement flow gating

Verification gates the whole lifecycle.

Verification status is a hard requirement on the actions that move money. POs and payments are blocked at the platform level for unverified suppliers - there is no path around it.

Action
Requires verified?
Create supplier
No · anyone can create a draft
Submit for approval
No · verification is recommended first
Approve supplier
Recommended · unverified suppliers flagged in UI
Place order / create PO
Yes · blocked if not verified
Make payment
Yes · blocked if not verified
Sync to Xero / QuickBooks / Sage
Yes · verified suppliers only
Before vs after

From "trust them on faith" to "verified at every layer".

Most procurement platforms verify nothing. The good ones verify the company. OmniPATH verifies the company, the VAT registration, the bank account validity and the account holder's name - automatically, before the first PO.

×
Without OmniPATH verification
Default state for most procurement tools
  • Company checks done manually - someone logs into the Companies House website
  • VAT checked by phone or email to the HMRC helpline
  • Bank details trusted on faith - no modulus or CoP check
  • Duplicate suppliers slip through - same company entered twice
  • Payment fraud possible - bank account doesn't belong to the named supplier
  • No audit trail - who checked what, when and what the result was
With OmniPATH verification
Four layers, audit-trailed, sub-five-second result
  • Companies House checked in real-time via API - active status, name, postcode
  • HMRC VAT validated automatically - VRN lookup with name cross-reference
  • Bank modulus check confirms sort code and account number are valid
  • Confirmation of Payee confirms the account holder matches the supplier name
  • Duplicate detection catches same company number or email within the org
  • Full audit trail - every check, every result, every override logged and fraud-tagged
LEDGE × Verification

Ask LEDGE about the state of your verification.

Every verification attempt, every failure code, every override is in the audit log. LEDGE has the whole picture. Ask in plain English - it'll cite the specific suppliers, codes and timestamps.

"How many suppliers are still unverified?"
"Show me all verification failures this month."
"Which suppliers failed CoP checks?"
"List suppliers verified with a skip_checks override."
"Are there any duplicate company numbers across our supplier base?"
"Which suppliers had their bank account switched in the last 30 days?"
Security & compliance

The bits your IT and audit teams ask about.

Standard government auth, OAuth where applicable, licensed scheme participation for the bank checks, full audit logs and zero personal data sent to third parties.

Government auth

Companies House: Basic Auth API key. HMRC: OAuth 2.0, read:vat scope only.

Bank Verification

Licensed bank verification API. Confirmation of Payee enabled.

Retry & failover

Exponential backoff, 3 retries on transient failures. tenacity on bank checks.

Sandbox mode

Full dev/test support without real network calls or real keys. Deterministic fixtures.

Audit trail

Every attempt logged. Failures fraud-tagged. Full failure detail kept on supplier and audit log.

Notifications

Admin alerted on every verification failure - inline UI flag plus the channel of their choice.

Admin override

skip_checks requires Admin role. Logged as an audit event with reason and operator.

Minimal data out

Only company number, VRN, sort code, account number and account holder name leave the platform.

Frequently asked

The practical details.

Does verification work for non-UK suppliers?
Currently no - all four layers are UK-specific. Companies House is the UK companies register; HMRC VAT covers UK VAT registrations only; the bank modulus check uses UK sort code validation tables; Confirmation of Payee verifies account holder names. For overseas suppliers, the supplier can still be created and managed in OmniPATH - verification just doesn't run and the supplier remains in unverified state. International register integrations (Irish CRO, French SIRENE, etc.) aren't currently on the platform.
How does this compare to Open Banking verification?
It's not Open Banking - it's the Confirmation of Payee scheme, which is the same name-check banks use during faster-payment processing. Open Banking is a different protocol focused on account information and payment initiation by consent. CoP is purpose-built for "is this account name actually who I think it is?" and runs without supplier-side authentication or consent flows - which makes it the right fit for procurement-side bank-detail verification.
Does verification re-run automatically over time?
Verification is point-in-time, not continuous. It runs when a supplier is created or submitted and again on demand when you click "Verify". There's no scheduled re-verification - companies can be dissolved, VAT registrations can be cancelled and bank accounts can be switched after verification. We surface the account_switched CoP outcome when payment time comes around (since CoP runs at payment time too in many setups), but supplier-side scheduled re-verification is not a feature today.
What happens when a verification check fails?
The full failure detail is stored as structured JSON on the supplier - code, message and which field caused the failure. verification_failed_at is timestamped. An admin notification fires immediately with the failure reasons. An audit event is created with the fraud=true flag set, so the failure shows up in fraud-tagged audit views and in LEDGE's fraud queries. The supplier remains in unverified state - POs and payments are blocked - until the issue is resolved or an Admin uses the skip_checks override (also audit-logged).
Can I override a verification failure?
Yes - Admin role only. The skip_checks flag forces the supplier into approved state without all four layers passing. Use cases: overseas suppliers (no Companies House record), sole traders without VAT registration, charities, edge cases. Every override is logged as an audit event with the operator and reason. LEDGE can pull the list of all skip-checks suppliers - useful periodic-review check for compliance teams.
Does Confirmation of Payee work with all UK banks?
Most major UK banks are CoP scheme participants - Lloyds, Barclays, HSBC, NatWest, Santander, Nationwide and so on. Some smaller institutions and building societies haven't enrolled. When the supplier's bank isn't a participant, the CoP layer returns not_supported - we treat this as a pass (no failure) since there's no name-check available, but it's flagged in the audit trail so your finance team knows verification was less strict for that supplier. The other three layers run normally.
What data leaves the platform during verification?
Only the fields the verification APIs need: company_no (Companies House), vrn (HMRC), sort_code + account_no (bank modulus) and account_holder_name + account_type (CoP). Email, phone, contact names, addresses-other-than-the-postcode and any other personal data stays inside OmniPATH. The verification services themselves are subject to government and government retention policies - they do not share their request logs with us beyond the response data.
Are sanctions, PEP or credit-risk checks included?
No - and we don't claim them. The four layers cover company existence, VAT validity, bank account validity and account-holder name match. Sanctions list screening (Dow Jones, Refinitiv, ComplyAdvantage) and credit-risk scoring (Dun & Bradstreet, Experian, CreditSafe) are separate categories of due-diligence and aren't part of the platform today. Some customers run those externally and import the result; we'd be happy to discuss native integrations if there's demand for a specific provider.
Ready when you are

See verification in action.

Add a test supplier on the demo and watch OmniPATH check Companies House, HMRC, the bank modulus and CoP in under five seconds. Bring a real supplier from your existing list if you want - we'll redact the bank details on screen.

30-min demo · Bring a supplier - we'll verify it live