VAT ID & Tax ID Capture

A VAT ID looks like this: a two-letter country prefix followed by eight to twelve digits (DE123456789, FR12345678901, IT12345678901), usually printed in small type near the vendor's name and address block, sometimes labeled "VAT No.," "USt-IdNr.," or "Numéro de TVA" depending on the country. It's not the invoice number, and it's not the tax rate. It's an identifier for the business itself, and on cross-border invoices it's often the first thing an accountant checks.

Here's the honest picture of how Glyf handles it: VAT ID and tax ID are not among the twelve fields extracted from a document today. If what you're after is to extract VAT from invoices as its own labeled column, that specific field doesn't exist yet. What Glyf does extract (Issuing Company, Primary Tax Rate, and itemized Tax Details) covers the tax-rate side of an invoice thoroughly. The identifier itself, when you need to confirm it, is something you check against the original document image rather than a dedicated structured field.

What you get today if you try to extract VAT from invoices

The twelve fields returned per document include Issuing Company, Primary Tax Rate (the main rate shown, returned as null when the document doesn't state it clearly rather than as a guess), and Tax Details, the itemized rate-and-amount breakdown when an invoice carries more than one tax rate. That covers the calculation side of tax on an invoice: what rate applied, how much tax was charged, and which entity issued the document. A dedicated VAT ID or tax ID field isn't part of that list, so if your workflow depends on having that specific identifier as a separate, exportable data point, that's a gap worth knowing about before you build a process around it.

Where to actually find the identifier

The Invoice Drawer's left side shows the original document image with pan and zoom, which is where you'd locate and confirm a VAT ID directly, the same place you'd already be checking Issuing Company and Tax Details for accuracy. Because the identifier sits in small print near the vendor block, zooming in on that specific area is usually faster than scanning the whole page. If your workflow needs the VAT ID recorded somewhere reviewable, the practical approach today is copying it from the original image into a field like Short Description or a tag during review, rather than expecting it to appear pre-populated as its own column.

Why the label varies by country

Part of what makes VAT ID review harder by eye is that the label itself changes depending on where the vendor is registered. Germany prints "USt-IdNr." France uses "Numéro de TVA" or sometimes just "TVA." Italy shows "Partita IVA." The Netherlands uses "BTW-nummer." Poland labels it "NIP." The format underneath is broadly similar (country prefix plus a run of digits), but the label you're scanning for on the page changes with every country a vendor is based in, which is part of why a quick visual scan across a batch of invoices from different suppliers can miss it even when it's printed clearly.

Why this distinction matters for EU-facing invoices

Cross-border invoicing inside the EU depends on VAT IDs for reverse-charge handling, intra-community supply reporting, and basic vendor verification. It's not a cosmetic detail, and treating it as one leads to gaps in a bookkeeping process. Knowing precisely what a tool does and doesn't capture as structured data matters more here than in most extraction contexts, because assuming a field exists when it doesn't is exactly how a compliance-relevant number ends up missing from an export nobody double-checked. If VAT ID and tax ID verification are a routine part of your invoice review, treat that verification as a manual step against the original document image for now, alongside the tax-rate fields that do extract automatically.

What this means for review and export

Tax Details and Primary Tax Rate carry through into your export the same way any other extracted field does: Excel's Summary and Line Items sheets, or the flattened CSV row per line item. VAT ID doesn't travel with them, since it isn't captured as structured data in the first place. If a specific invoice is missing a critical field entirely (invoice number, date, total cost, currency, issuing company, category, short description, or line items without a description or total), it's automatically flagged "Needs Attention," but that flag has nothing to do with whether a VAT ID happens to be present or absent, since it isn't one of the tracked fields.

Where this fits in the broader invoice workflow

Tax-rate extraction, VAT ID review, and the rest of the invoice workflow work together rather than as separate processes. For the field-by-field detail on how Primary Tax Rate and Tax Details extract and export, see Line Items & Tax Extraction. For the wider invoice extraction picture this fits into, see Intelligent Extraction for Invoices. And since VAT-adjacent workflows often come with data-residency questions, our EU hosting and GDPR compliance page covers where documents are stored and processed.

FAQ

Does Glyf extract VAT ID as its own structured field? Not currently. The twelve extracted fields cover Issuing Company, Primary Tax Rate, and itemized Tax Details, but not a dedicated VAT ID or tax ID field. You'd confirm the identifier against the original document image in the Invoice Drawer.

Does Glyf validate whether a VAT ID is correctly formatted or currently active? No. Glyf doesn't perform VAT number validation against any registry. Confirming validity is a separate step outside the extraction workflow.

If VAT IDs matter for my bookkeeping, what should I do in the meantime? Use the Invoice Drawer's zoomed document view to locate and record the identifier manually, into a tag or the Short Description field, alongside the tax-rate data that extracts automatically.