Reconcile vendor identities
Match supplier records to legal names, registration numbers and available VAT or EIN identifiers. Retain the original vendor ID so teams can review exceptions and update the correct record.
Vendor master data cleansing →VATFIND COMPANY DATASETS
Bring legal-company names, VAT numbers, US EINs and registration details into your supplier master, finance platform or company-data warehouse. Define the countries, fields and update schedule around your enterprise workflow.
A COMPANY DATASET FOR ENTERPRISE SYSTEMS
A company dataset is a collection of business records that your systems can match, join and analyse. A bulk data feed delivers an agreed population of those records together, with a documented schema and update process. VATFind focuses on legal-company identity, VAT and tax identifiers, and the company context needed to use them.
Start with a defined country population or a company list you need to enrich. Agree the required fields and delivery rules, review a representative sample, then load the accepted data into your platform. Each feed is scoped commercially and technically; record counts and field coverage are confirmed for that population.
Match supplier records to legal names, registration numbers and available VAT or EIN identifiers. Retain the original vendor ID so teams can review exceptions and update the correct record.
Vendor master data cleansing →Add available addresses, business identifiers and company status to finance data. Compare changes with your existing records before applying them to the ERP.
Tax and finance enrichment →Build a company reference layer for retrieval-augmented generation. Keep company keys, countries, source context and timestamps alongside indexed company facts.
Company datasets for RAG →COMPANY DATA AND BUSINESS IDENTIFIERS
A useful B2B company dataset needs more than company names. Your sample should show whether the identifiers, jurisdiction, source context and attributes required by your workflow are present. The table below identifies field groups to discuss; the accepted data dictionary defines the exact production columns.
| Field group | Possible content | Acceptance question |
|---|---|---|
| Entity identifiers | Contracted company key, country and source identifiers | Define key stability and how records join across deliveries. |
| Legal-company identity | Legal name, registration number and legal form | Distinguish legal entities from brands, branches and trading names. |
| VAT and business tax IDs | Available VAT numbers, US EINs and supported tax identifiers | Retain identifier type and country; preserve leading zeros as text. |
| Company context | Registered address, legal status and incorporation details | Confirm field availability in the target countries and population. |
| Source context | Source category, name or URL where supplied, and retrieval time | Distinguish record retrieval time from the date a source field changed. |
| Update metadata | Agreed operation, sequence and effective or observed time | Specify how inserts, changes, removals and late records are applied. |
Availability varies by country, source and company. A missing VAT number, EIN or incorporation date should have a documented meaning. Separate fields that were not returned from fields that are outside the contracted coverage.
CSV, JSON & COMPANY KEYS
Discuss CSV or JSON-based delivery according to your ingestion process. For a company dataset in CSV, define encoding, delimiters, date formats and how multiple tax IDs appear. JSON can preserve arrays and nested source context. Format and transfer are confirmed during feed design.
Store VAT numbers, EINs and registration numbers as text so leading zeros survive ingestion. Keep the issuing country beside each identifier and retain your own vendor or customer key in the mapping.
The example shows a possible record shape. The production field names, identifiers and change metadata are agreed for the feed; it is not the public REST response schema.
{
"enterprise_company_key": "customer-company-1048",
"country_code": "GB",
"legal_name": "Example Company Limited",
"registration_number": "01234567",
"vat_numbers": ["GB123456789"],
"source_context": {
"source_name": "VATFind",
"retrieved_at": "2026-09-08T09:00:00Z"
},
"change": {
"operation": "upsert",
"sequence": 1042
}
}Use the entity key and country to join company records before creating embeddings or retrieval documents. Preserve source context in the retrieved passage and refresh records according to the agreed feed cadence. Live, on-demand follow-up questions can use the API or MCP.
BULK DATA, API OR MCP?
| Option | Best fit | How access works |
|---|---|---|
| Bulk company dataset | An initial data load, supplier-master enrichment or a recurring warehouse refresh. | Agreed population, fields, format, cadence, delivery and licence. |
| Company data REST API | Individual searches and identifier checks inside an application. | API key, documented endpoints, rate limits and workspace credits. |
| MCP server | An AI assistant requesting company evidence as it works. | OAuth connection, discoverable tools and workspace credits. |
Bulk VAT checks are a different workload from a dataset delivery. If you have a list of supplied VAT numbers or EINs to check, the REST API can process individual requests within its limits. If you need company records delivered together for reuse, discuss a bulk feed. Neither a company dataset nor a company-record match establishes live VAT-registration status.
DELIVERY METHOD PLANNER
This planning aid is illustrative. Final coverage, format, cadence, rights and pricing are confirmed for the agreed scope.
Start with an accepted snapshot, then agree how incremental changes, replays and removals are represented.
Request a dataset sample A recommendation is not a coverage or entitlement confirmation.A full snapshot supplies the agreed population at a point in time. Incremental delivery supplies the agreed changes since an earlier delivery. Define how new records, modified fields, removals, late-arriving changes and replayed files should be handled before choosing the update pattern.
Retain an accepted baseline and reconcile each delivery against it. A record disappearing from a feed does not by itself mean the company was dissolved. Your specification should distinguish a scope change, an unavailable source and a genuine company-status event.
SAMPLE, QUALITY & PRICING
Provide representative records from your intended population, including difficult names, missing IDs, multiple jurisdictions and inactive companies. Measure how the sample performs against the same rules you will use in production.
| Measure | What to calculate or inspect |
|---|---|
| Company matching | Confirmed matches divided by submitted eligible records; review ambiguous candidates separately. |
| Field completeness | Returned values for each required field, measured separately by country. |
| Identifier quality | Country and type consistency, preserved leading zeros and correct mapping to the legal entity. |
| Duplicate handling | Repeated source records, branches, subsidiaries and multiple identifiers for one company. |
| Update behaviour | How your system applies a changed record, missing field, late delivery and replayed file. |
| Evidence retention | Whether source context, observation times and accepted delivery versions remain traceable. |
Countries, company list, required fields and business purpose.
Confirm record coverage, field meaning and matching outcomes.
Format, transfer, cadence, update rules and acceptance criteria.
Load the baseline and track changes and exceptions in your system.
The quote depends on the countries, population, fields, refresh frequency, delivery requirements and use rights. Bulk data is scoped separately from self-service API subscriptions. Include these requirements when requesting a sample so pricing reflects the intended deployment.
Confirm who will use the dataset, where it will be stored, retention periods and any redistribution, resale, derivative-product or AI use. These rights are defined in the written agreement for your feed.
COMPANY DATASET QUESTIONS
VAT and EIN fields, CSV and JSON, update cadence, company matching, samples and licensing.
A company dataset is a collection of business records for matching, enrichment or analysis. A bulk feed delivers an agreed population with a defined schema and update process. VATFind scopes legal-company identity, VAT and tax identifiers, company context and delivery requirements for enterprise systems.
Yes, where available in the agreed country population. The specification should identify VAT numbers, US EINs and other business tax IDs separately, alongside legal names, registration details and country codes. The sample establishes actual coverage and missing-value behaviour.
Discuss CSV or JSON-based delivery during feed design. Agree encoding, delimiters, dates and how arrays or multiple identifiers are represented. Store VAT, EIN and registration identifiers as text to preserve leading zeros. The production format is confirmed in the feed specification.
A company dataset delivers records for reuse in your systems. A VAT-checking workload starts with a list of supplied numbers and requests a result for each. VATFind supports individual company-record checks through REST; a dataset or company association does not establish live VAT-registration status.
An enterprise feed can be scoped around a supplied company population. Include your internal record key, countries and available identifiers, then evaluate matching and field completeness on a representative sample before agreeing production delivery.
The refresh cadence is agreed for the feed. Delivery may use a one-time load, recurring full snapshots or an incremental update design. Specify how new, changed, removed, replayed and late-arriving records are represented and applied.
REQUEST A COMPANY DATASET
Tell us the company population, data attributes, format, refresh schedule and intended use. We’ll review the scope and sample requirements.