The cross-border vendor that almost got paid against a VAT number that did not exist

This is a story about a contract that nearly went out clean, and the twenty minutes of setup that stopped it. No mocked screens, no toy data. Every registry record, UEN, and VAT result below is a real lookup against a live official source, captured from an actual chat.

The setup

Marcus runs revenue operations at a US software company. When the business signs a new vendor, he owns the last gate before legal countersigns and finance sets up the payee. Most of the time that gate is a formality. This week it was not.

The vendor was a cross-border one, which is where these deals get slippery. The contracting party was a Singapore entity. The invoices, though, would come from a separate EU entity in France, with a VAT number on them so finance could handle the tax treatment. Two legal entities, two jurisdictions, one signature about to bind them all.

Marcus had learned the hard way that a name on a contract is not proof of anything, and a VAT number on an invoice is just a string of digits until something authoritative says otherwise. Before he would move the contract forward, two things had to be true:

1. The Singapore company has to be a live, registered entity, and he needs its UEN (Unique Entity Number) to set up the payee correctly, not a similarly named shell.
2. The EU VAT number on the invoice has to be valid and resolve to the entity that is actually billing us. If it does not, finance cannot reclaim the input VAT, and the contract is exposed at the next audit.

For years this meant two government websites, two search boxes, and a lot of squinting at screens in languages he does not read. It was reliable exactly as long as he was not rushed. Onboarding is always rushed.

So a couple of weeks earlier, Marcus had done something different. He wired both data sources directly into Claude as tools, using the official Apify MCP server, and let the model do the fetching. It took one config block and a restart.

The two tools he connected:

• The Singapore ACRA Company Registry Scraper looks up any Singapore company on the official ACRA corporate register and returns the UEN, entity status, incorporation date, registered address, industry codes, and former names.
• The EU VAT VIES Validation Scraper validates one or many EU VAT numbers against the European Commission's VIES service and, where the member state provides it, returns the registered trader name and address.

Both exposed to Claude through a single MCP endpoint. Nothing else changed about how Marcus works: he opens a chat and types in plain English.

Check one: is the Singapore company real?

The contracting entity on the paperwork was "DBS Bank Ltd". Marcus pasted the name into Claude and asked it to confirm the company was live and pull the UEN.

Two seconds of tool call, and he had a clean answer straight off the official register. DBS BANK LTD. came back as a Live Company, UEN 196800306E, a Public Company Limited by Shares incorporated on 16 July 1968, registered at 12 Marina Boulevard, and even carrying its former name (The Development Bank of Singapore) in the record.

But the useful part was the thing Marcus would not have thought to look for. The same search surfaced a near-namesake, DBS PTE. LTD., UEN 197700546G, that was Dissolved through a members' voluntary winding up. Claude flagged it unprompted: a different legal entity with a confusingly similar name, and it warned him to make sure the payee and the contract were set up under 196800306E, the live one, not the dead namesake sitting one row away in the register.

This is exactly the trap that catches busy teams. The name matches. The UEN does not. Set finance up against the wrong one and you have wired money to an entity that legally no longer exists. The agent caught it and said which UEN to trust, with the register as evidence.

Check two: does the VAT number hold up?

The Singapore side cleared. Now the EU billing entity. The invoice draft carried a French VAT number, and the vendor's master-data form listed two more numbers for good measure. Marcus asked Claude to run all of them through VIES and tell him which one finance could actually pay against.

The answer stopped the invoice.

The number printed on the invoice, FR99999999999, came back INVALID. VIES had no such registration. In plain terms: if finance had paid that invoice as it stood, the input VAT would not have been reclaimable and the document would have failed audit. It was not a live registration at all, just a plausible-looking string of the right length.

The corrected French number, FR40303265045, came back VALID and, better still, resolved to a real registered trader: SA SODIMAS, at 11 Rue Ampere, 26600 Pont de l'Isere. That is the piece that makes VIES more than a yes/no check. The name and address it returns are the thing Marcus can reconcile against the EU entity written into the contract. Valid and matching is the bar, not valid alone.

The third number, a German VAT (DE811193231), was VALID too, though Claude was careful to note that Germany does not return a trader name through VIES, only the confirmation, so that one has to be matched to the contract by number rather than by name. An honest caveat, surfaced without being asked, rather than a false sense of a name match that VIES never actually provided.

So the picture was: the vendor genuinely holds a valid EU VAT registration, but the number their own invoice carried was not it.

The memo

The last step is the one that used to eat the most time: writing it up so someone else can trust the decision. Marcus asked Claude to consolidate everything into a single go/no-go table he could staple to the contract approval.

Five lines, each tied to the identifier it rests on. The Singapore counterparty: GO, under UEN 196800306E. The dissolved namesake: do not use. The EU entity SA SODIMAS: GO, on a valid VAT that returns a matching name. The number actually on the invoice: NO-GO, reject and re-issue. The secondary German VAT: fine, match by number.

The bottom line the agent wrote was not "approved" and it was not "blocked." It was the precise, defensible thing: cleared to sign once the vendor re-issues the invoice against the valid VAT number. Both lookups had run against official sources that morning, and both run IDs were in the memo, so the approval file was audit-ready the moment it was written.

What actually changed

Nothing about Marcus's judgment moved to the machine. He still decides which vendors to onboard and when to hold a signature. What moved was the mechanical part that fails under time pressure:

• The fetch is automated. Claude pulls the live ACRA record and runs the VAT numbers through VIES on its own, the moment the conversation needs them, in jurisdictions and languages Marcus does not have to navigate by hand.
• The evidence is preserved. Every answer cites a UEN or a VAT number and the run it came from, so the output is audit-ready by default instead of a screenshot someone took and lost.
• The check is consistent. The same two-part screening happens on vendor one and vendor fifty, whether or not anyone is watching the clock.

Two problems got caught before the contract went out: a dissolved namesake that could have become the payee, and an invalid VAT number that would have surfaced months later as an audit finding. On a rushed onboarding, with the old two-tab process, at least one of them slips through.

Build the same agent

Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

1. Get your Apify API token from the Apify Console under Settings → Integrations.
2. Add the official Apify MCP server to your client and list the two Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/singapore-acra-entities-scraper,scrapers_lat/eu-vat-vies-validation-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

1. Restart the client and ask it, in plain English, to verify a Singapore counterparty and validate the VAT number on its invoice. It will pick the right tool for each step.

📌 Note: each tool call is a real Actor run billed to your Apify account (both are pay-per-result, a fraction of a cent per lookup). For continuous screening of a whole vendor master, run the Actors on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: the same pattern scales to any jurisdiction or check. Add UK Companies House for British counterparties, or the OFAC Sanctions List Screening Scraper to screen the same party against the US Treasury list, and your onboarding agent covers more ground without a single line of new code.

The Actors used in this story: Singapore ACRA Company Registry Scraper and EU VAT VIES Validation Scraper.