Verificare TVA
Analytics & DataCheck the VAT position of Romanian companies against official sources by tax identification number and reference date. Agents confirm a counterparty's VAT status before invoicing them.
What This Integration Enables
A VAT number is not the fact you need. The fact you need is the VAT position a company held on a specific day, because an invoice is a dated document and the treatment it carries has to be right on its own date rather than on the date somebody happens to run the check. Verificare TVA takes a reference date as a first-class parameter, which is why it belongs in a reconciliation flow and not just in a signup form. The same CUI asked about January and asked about June can legitimately return two different answers, and a workflow that ignores that is validating the wrong thing correctly.
One call carries the whole picture for one or many Romanian companies. It reports whether the company is VAT registered, whether it applies VAT on collection, whether it applies split VAT payment, whether it is or has ever been flagged inactive by ANAF, and whether it is enrolled in the RO e-Factura registry. Alongside that come the registered name, trade register number, CAEN activity code, registration date, and both the registered office and the fiscal domicile addresses, which are frequently not the same address and frequently matter. Answers are served from the VerificareTVA cache unless Real Time Lookup is turned on, in which case they are read directly from ANAF, so a flow chooses between speed and freshness deliberately rather than by accident. Companies that cannot be resolved come back in a notfound array with a per-company reason such as INVALID or DUPLICATE, which is a much more useful shape than a failed batch. Requesting the balance sheet or the Trade Registry status consumes two subscription queries instead of one, so a flow that pulls them on every record is spending twice for data most records do not need.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Deciding How to Invoice a New Customer
A Romanian company completes onboarding and supplies a CUI. The agent runs Verify Romanian VAT Status at today's date and gets more than a yes or no. Whether the customer applies VAT on collection, whether split VAT payment is in play, and whether they are enrolled in RO e-Factura are three separate flags that shape how the invoice is built and how it is delivered, and they need to be known before the first document is raised rather than discovered when it bounces. The agent writes the registered name, trade register number, CAEN code, and both addresses onto the account in Attio or the ERP, so the billing entity is the registry's version rather than whatever the sales rep typed. The registered office and the fiscal domicile are stored as distinct fields, because a company that receives post at one and is taxed at the other will notice if you conflate them.
Screening Suppliers Before Payment
Before a supplier payment batch releases from NetSuite, the agent runs the whole payee list through a single batched call and reads two things in particular: whether each supplier is currently flagged inactive by ANAF, and whether they have ever been. A supplier who has been inactive in the past and is not now is a different conversation from one who is inactive today, and the response distinguishes them. Payees whose records resolve cleanly and carry no inactive flag continue. Payees who land in the notfound array with a reason of INVALID or DUPLICATE are separated out as data problems, which is what they are, rather than being treated as compliance findings. What reaches the payments lead is a short list with a stated reason per line.
Reconstructing the Position at the Invoice Date
At period end the agent walks the invoices issued during the period and, for each one, calls Verify Romanian VAT Status with that invoice's own date as the reference date rather than with today's. This is where the reference date earns its keep. A customer who deregistered in February will validate cleanly today and validate cleanly for a January invoice, and will not validate for a March one, and only a per-document check finds that. The agent compares the returned position against the treatment printed on each invoice, then hands the disagreements to a person along with the registry record that produced them. The check that used to be a sampling exercise becomes a full pass, because a full pass costs one batched call rather than an afternoon.
Human-in-Loop Highlight
The stop happens when a mismatch is found on an invoice that has already left the building. Correcting it means issuing a credit note or a corrected document, and that reaches the customer: it changes what they owe, it changes what they can claim, and it cannot be quietly reversed once sent. It is also a decision with tax consequences that the agent is not qualified to take, because whether and how an already-issued document must be corrected is a question for your finance function and its advisors, not for a connector that read a registry. So the agent stops and hands over a complete case: "Invoice 2026-0417, issued 14 March, customer [name], CUI [number], VAT charged at the standard rate. Verify Romanian VAT Status as at 14 March returns: not VAT registered, ANAF inactive flag set from 2 March, RO e-Factura not enrolled. Registered name on file matches. Issue a credit note, reissue the document, or hold pending advice?" The controller decides and their decision is recorded against the invoice and the registry response together. The batched check itself is what connectors are for and it needs nobody watching it. The correction that reaches a customer is where a person belongs, and putting one there deliberately is the difference between an agent you can leave running and an agent you have to supervise.
Agent Capabilities
1 actionsVAT Verification
1- Verify Romanian VAT Status Looks up the official fiscal record of one or more Romanian companies by tax identification number and returns their VAT position for a given date. The response reports whether the company is VAT registered, whether it applies VAT on collection or split VAT payment, whether it is or has been flagged inactive by ANAF, and whether it is enrolled in the RO e-Factura registry, together with the registered name, trade register number, CAEN activity code, registration date, and both the registered office and fiscal domicile addresses. Data is served from the VerificareTVA cache unless Real Time Lookup is enabled, in which case it is read directly from ANAF. Companies that cannot be resolved are returned in a notfound array with a per-company reason such as INVALID or DUPLICATE. Requesting the balance sheet or the Trade Registry status consumes two subscription queries instead of one.
Frequently Asked Questions
What can FlowRunner do with Verificare TVA?
FlowRunner agents can run Verify Romanian VAT Status in Verificare TVA.
Does connecting Verificare TVA to FlowRunner require OAuth?
No. Verificare TVA connects to FlowRunner with an API key, no OAuth flow required.
Can Verificare TVA trigger a FlowRunner workflow automatically?
Verificare TVA doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Verificare TVA
$100 in credits. No card required. Connect in minutes.