Check any CUI before you invoice: automate ANAF VAT & e-Factura lookup with Power Automate

Scenario: pre-invoice validation for every Romanian customer

You’re working with a small finance/ops team that:

• Issues hundreds of invoices per month to Romanian entities.
• Stores customer data in Dataverse or SharePoint (CUI, name, address, payment terms).
• Must comply with e-Factura rules and avoid issuing invoices to inactive VAT payers.

Today’s process:

1. A draft invoice is created in your ERP or a custom app.
2. Someone opens ANAF’s "Verificare CUI" web page.
3. They manually type the CUI, read the VAT status, then mark a checkbox in the invoice ("validated").

Pain points:

• Manual lookups are slow and error-prone.
• Nobody re-checks status changes for recurring customers.
• There’s no auditable trail of what ANAF returned at invoice time.

Target state:

• Whenever a draft invoice is created (or a customer is added/updated), a Power Automate flow calls ANAF’s public CUI verification service.
• The flow writes:
  • VAT registration status.
  • VAT-on-collection (TVA la încasare).
  • Inactive status.
• The invoice can’t be issued until ANAF validation is present and recent.

We’ll build that flow step by step.

What ANAF’s public CUI services actually give you

ANAF exposes public, no-login services that return multiple tax-related flags for a Romanian CUI. For invoicing compliance, the key points are:

• VAT registration – whether the entity is registered for VAT.
• VAT-on-collection (TVA la încasare) – whether VAT is due on payment rather than on invoicing.
• Inactive status – whether the taxpayer is declared inactive.

ANAF publishes these via HTTP-accessible services that:

• Accept CUI (and usually date) as parameters.
• Return structured data (commonly XML, sometimes JSON via intermediaries) with fields for each status.
• Are intended for high-volume “Verificare CUI” queries and typically do not require authentication.

From Power Automate’s perspective this is workable: one HTTP call per CUI, no login flow, and you can parse the response into strongly typed fields in your data store.

e-Factura and split VAT: ANAF’s e-Factura register and historical split VAT mechanism are exposed via separate datasets/services, not the basic CUI verification service. If you need e-Factura enrolment or split VAT history, you must:

• Identify the current official ANAF source (e.g., downloadable register files or dedicated endpoints).
• Build separate flows or logic to ingest and join that data to your customer records. The rest of this article focuses on the core CUI verification (VAT and inactivity), which is the stable part of the process.

Why you need the premium HTTP connector

Power Automate has multiple ways to call web services, but for ANAF’s services you’ll almost always use the HTTP action, which is part of the premium connector set.

Important licensing implications (as of late 2026):

• The HTTP action is a premium capability in cloud flows.
• Using this action requires:
  • A standalone Power Automate per-user or per-flow license, or
  • A Power Apps / Dynamics 365 license that includes premium connectors.
• If your tenant only has Microsoft 365 licenses without premium entitlements, the HTTP action will be marked as requiring additional licensing and may not run.

There are workarounds (e.g., Azure Functions or custom connectors managed centrally), but they still consume premium capacity somewhere. For a dedicated invoicing validation flow, budgeting for a premium license is usually simpler.

Flow design: when and how to call ANAF

Before we touch actions, decide on the trigger and the data store.

Trigger options

For the invoicing scenario, common triggers are:

• When a row is added, modified or deleted (Dataverse)

  • Trigger when a new invoice or customer record is created or updated.
  • Use conditions to only run when the CUI changes or when validation is missing/expired.

• When an item is created or modified (SharePoint)

  • Same idea, but with a SharePoint list behind your invoicing app.

• Recurrence (scheduled)

  • Nightly batch to re-validate all active customers whose last check is older than X days.

For a high-volume “Verificare CUI” use case, a batch + per-invoice check is often safest:

• Batch: ensures your customer master stays current.
• Per-invoice: ensures you have up-to-date ANAF data at invoice time.

Data model for ANAF response

Regardless of whether you use Dataverse or SharePoint, define fields to store the ANAF data. Typical fields:

• CUI (string)
• ANAF_LastCheckedOn (date/time)
• ANAF_IsVATRegistered (boolean)
• ANAF_IsVATOnCollection (boolean)
• ANAF_IsInactive (boolean)
• ANAF_RawResponse (text, optional for audit/debug)

With this structure, your ERP or invoice app can enforce rules like:

• Block invoicing if ANAF_IsInactive = true.
• Apply different invoice templates if ANAF_IsVATRegistered = true.
• Adjust due dates or payment instructions if ANAF_IsVATOnCollection = true.

Building the Power Automate flow step by step

We’ll assume:

• Customer records live in a Dataverse table Accounts with a CUI column.
• You have a premium license that allows the HTTP connector.

1. Create the flow and trigger

1. In Power Automate, create a Cloud flow.

2. Choose When a row is added, modified or deleted (Dataverse) as the trigger.

3. Configure:

   • Change type: Added or Modified.
   • Table name: your Accounts table.
   • Scope: as appropriate (e.g., Organization).

4. Add a Condition after the trigger to avoid unnecessary calls:

   • Condition: CUI is not empty, and ANAF_LastCheckedOn is either empty or older than X days.

You can implement the age check using a combination of addDays(utcNow(), -X) and comparison in an expression.

Example pattern for "older than 7 days" (you will adapt this to your actual actions and columns):

@or(
  equals(triggerOutputs()?['body/ANAF_LastCheckedOn'], null),
  lessOrEquals(triggerOutputs()?['body/ANAF_LastCheckedOn'], addDays(utcNow(), -7))
)

This assumes ANAF_LastCheckedOn is present on the row from the trigger. If you use a separate Get a row by ID action, adjust the expression to reference that action instead.

2. Call ANAF via HTTP (premium)

Add an HTTP action inside the "Yes" branch of the condition.

Configure the HTTP action:

• Method: GET or POST depending on the specific ANAF service you target.
• URI: the ANAF endpoint for CUI verification.
• Headers: set Content-Type if required (e.g., application/xml or application/json).
• Query/body: include the CUI and date parameters as required.

The exact URI and parameter format depend on ANAF’s current service; you must copy them from ANAF’s official site or documentation. Use dynamic content to insert the CUI from the Dataverse row into the request.

Example pattern (structure only, not a real endpoint):

{
  "method": "GET",
  "uri": "https://<anaf-endpoint>/verificarecui?cui=@{triggerOutputs()?['body/CUI']}&date=@{utcNow()}"
}

Replace the base URL and parameter names with the actual ANAF values.

3. Parse the ANAF response

ANAF’s response format (JSON vs XML, field names) is defined by ANAF, not Microsoft. Once you know the format, use either:

• Parse JSON if the response is JSON.
• Compose + XML actions (such as XML, Select, Compose) if the response is XML.

Assuming JSON, add a Parse JSON action:

1. Content: @body('HTTP') (or the name of your HTTP action).
2. Schema: generate from a sample response you copy from ANAF’s site or a test call.

The schema will expose fields such as (example names only):

• isVATRegistered (boolean)
• isVATOnCollection (boolean)
• isInactive (boolean)

You must align these with the actual ANAF field names.

If the response is XML, first convert it to JSON or extract the needed nodes using Power Automate’s XML functions, then map them to your Dataverse fields.

4. Write back to Dataverse

Add an Update a row (Dataverse) action to store the ANAF data on the account.

Map fields:

• Row ID: from the trigger.
• ANAF_LastCheckedOn: utcNow().
• ANAF_IsVATRegistered: isVATRegistered from Parse JSON (or the equivalent XML-derived value).
• ANAF_IsVATOnCollection: isVATOnCollection.
• ANAF_IsInactive: isInactive.
• ANAF_RawResponse: @string(body('HTTP')) (optional).

This gives your downstream systems a single source of truth for ANAF status per CUI.

5. Handle errors and edge cases

You don’t want a temporary ANAF outage to block all customer updates.

Add basic error handling:

• Wrap the HTTP + Parse JSON/XML + Update row in a Scope.
• Add a second Scope for error handling.
• Configure Run after on the error scope to trigger on has failed or has timed out.

In the error scope, you can:

• Set ANAF_LastCheckedOn to null or leave unchanged.
• Log an error record in a separate table.
• Notify finance via email or Teams when ANAF cannot be reached.

This keeps your flow resilient while still enforcing validation most of the time.

Using the ANAF data in your invoicing process

Once the ANAF flags are stored, you can enforce rules in multiple layers.

In Power Apps or custom front-ends

If you have a model-driven app or canvas app for invoicing:

• Disable the "Issue invoice" button when:

  • ANAF_IsInactive = true, or
  • ANAF_IsVATRegistered = false for customers that should be VAT payers.

• Show warnings when:

  • ANAF_IsVATOnCollection = true (adjust payment handling).

If you also ingest e-Factura enrolment data from ANAF’s official register via a separate process, you can:

• Show warnings when a customer is in the e-Factura register but your invoice isn’t prepared for e-Factura.

In Power Automate invoice flows

If you generate invoices via flows:

• Add a Condition that checks the ANAF fields before creating the invoice in ERP.
• Route invoices differently based on additional flags you maintain (e.g., e-Factura enrolment from a separate register import):
  • If the customer is marked as e-Factura-enrolled in your data model, send the invoice to your e-Factura integration.
  • Otherwise, send via email or other channels.

Audit and compliance

Because you store ANAF_LastCheckedOn and optionally ANAF_RawResponse:

• You can prove what ANAF returned at the time you issued the invoice.
• You can regularly re-check customers via a scheduled flow and compare for status changes.

For the finance team, this is a concrete improvement over ad-hoc screenshots and manual notes.

Performance and volume considerations

"Verificare CUI" is a high-volume search pattern. A few points to keep your flow healthy:

• Avoid duplicate calls

  • Only call ANAF when the CUI changes or when your last check is older than your chosen threshold.

• Batch vs real-time

  • Real-time checks at invoice creation give the most accurate data.
  • Nightly batch checks on all active customers smooth out load and keep your master data fresh.

• Timeouts and retries

  • The HTTP action supports timeout and retry policies.
  • Use conservative retry settings; if ANAF is down, spamming retries won’t help.

• Rate limits

  • ANAF may enforce server-side limits on request rate.
  • If you see throttling behaviour, add delays or queueing logic (e.g., use a queue table and a scheduled flow to process in chunks).

One practical takeaway

Before your next invoicing cycle, pick one customer table (Dataverse or SharePoint), attach a Power Automate flow with a premium HTTP call to ANAF’s CUI verification service, and write back VAT and inactivity flags per CUI. Once you see those fields driving real conditions in your invoice flow, manual "Verificare CUI" checks will quickly become the exception instead of the rule.