# Romanian company register (ONRC identity data republished by ANAF)

> Romanian companies and other taxpayers with the identity fields ANAF republishes from the Trade Register: the ONRC registration number, the CAEN activity code, the legal and organisational form, the registered office, the competent tax office and the VAT / inactive status. Alongside it, the daily snapshot of ANAF's register of taxpayers on the VAT-cash-accounting regime (TVA la încasare), which ANAF publishes as a complete file every day, together with that register's event history. PERSONAL DATA WARNING: a large share of Romanian CUIs belong to PFA, individual enterprises and professionals, where the entity name is a natural person's name and the registered office is often a home address. The source is ANAF because data.gov.ro, where ONRC publishes the full bulk download, was not responding when this connector was built.

- Dataset id: `anaf-company-register`
- Update cadence: daily
- Upstream source: https://static.anaf.ro/static/10/Anaf/TVA_incasare/modalitati_consultare_registrul_contribuabili.htm
- Tags: romania, companies, business-register, onrc, anaf, caen, vat, tax, open-data
- Current version: ingest `01M5H0M8XKYN3BWY4GC5WBT2SF`, snapshot 2026-10-22, generated 2026-10-22T06:45:23.004Z

## Licence and attribution

- Licence: Romanian official acts and public-interest information — outside copyright (`ro-official-acts-public-domain`)
- Licence text: https://legislatie.just.ro/Public/DetaliiDocument/7816
- Required attribution: Date despre firme din registrele publice ANAF — Agenția Națională de Administrare Fiscală (anaf.ro)
- Notes: Legea 8/1996 privind dreptul de autor, art. 9, excludes from copyright both official texts of an administrative nature and simple facts and data. The company register fields republished here — denumire, numărul de înregistrare la registrul comerțului, codul CAEN, sediul, starea de înregistrare — are both: they are the official record of an administrative act, and the entries themselves are bare facts. They are also public-interest information under Legea 544/2001 and re-usable public-sector information under Legea 179/2022, which transposes the EU Open Data Directive — note that this is a REUSE RIGHT held against a public body, not a copyright licence granted to the world. ANAF states that the VAT-cash register is public, on the page this dataset takes it from: "acest registru va fi public pentru contribuabili" (https://static.anaf.ro/static/10/Anaf/TVA_incasare/modalitati_consultare_registrul_contribuabili.htm). ANAF's web-service documentation (http://static.anaf.ro/static/10/Anaf/Informatii_R/doc_WS_V6.txt) imposes technical limits on the per-CUI service — "Un client poate executa maxim 1 request pe secunda", "Un request poate contine maxim 500 de CUI-uri" — and warns that "orice tentativa de suprasolicitare a serverului va fi pedepsita conform reglementarilor in vigoare". This connector honours both: strictly sequential requests, at most 500 CUIs each, never faster than one per second, and one run refreshes a deterministic slice of the CUI universe rather than sweeping all of it. ANAF publishes no dataset-specific licence for either surface, so anyone republishing this data should make their own assessment rather than relying on this note. PERSONAL DATA (GDPR): a large share of Romanian CUIs belong to PFA, întreprinderi individuale, întreprinderi familiale and individual professionals. For those the entity name IS a natural person's name, and the registered office IS very often that person's home address, including the apartment number in `address_details`. Publishing the trade-register record is lawful in Romania, but a reuser is processing personal data and owes the corresponding duties — purpose limitation, and in particular not assembling it into a profile of a private individual. WHAT IS DELIBERATELY NOT PUBLISHED: the bank account (`iban`) ANAF returns for every taxpayer, which is a payment credential and is needed by nothing this dataset is for, and the fax number. `phone` is published because it is the taxpayer's declared business contact field, and it is NULL for the large majority of rows. The VAT-cash register is republished in full because ANAF publishes it in full, as a complete daily file intended for exactly this kind of local consultation.

Reproduce the attribution line verbatim anywhere you republish this data.

## Manifest

- Start here for how this directory works: https://data.bunnytech.app/llms.txt
- This dataset: https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/manifest.json
- All datasets: https://data-directory.fsn1.your-objectstorage.com/public/index.json
- Human page: https://data.bunnytech.app/datasets/anaf-company-register

The manifest is the contract: file URLs, row counts, column types, min/max statistics and
example queries all live there. Re-read it to discover a new version.

## Fastest path — Parquet exports

Immutable, physically sorted snapshot exports. No catalog fetch, best row-group pruning,
safe to cache forever. Register one view per table:

```sql
INSTALL httpfs; LOAD httpfs;

CREATE OR REPLACE VIEW companies AS
  SELECT * FROM read_parquet('https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/companies.parquet');

CREATE OR REPLACE VIEW vat_cash_register AS
  SELECT * FROM read_parquet('https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/vat_cash_register.parquet');

CREATE OR REPLACE VIEW vat_cash_events AS
  SELECT * FROM read_parquet('https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/vat_cash_events.parquet');

CREATE OR REPLACE VIEW lookup_coverage AS
  SELECT * FROM read_parquet('https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/lookup_coverage.parquet');
```

Example queries:

-- Find a company by name and get its Trade Register number: The one query the companies table is physically sorted for. name_lc is the folded name, so the prefix predicate is a range on the sort column and row-group statistics prune the file instead of scanning it — and "dante" finds "DANTE" as well as "Dănţe".
```sql
ATTACH IF NOT EXISTS 'ducklake:https://data-directory.fsn1.your-objectstorage.com/catalog/catalog.ducklake' AS "datadirectory" (READ_ONLY);

SELECT cui, name, reg_com_number, caen_code, county, registration_status
FROM datadirectory.anaf_company_register.companies
WHERE name_lc >= 'dante' AND name_lc < 'dante' || chr(255)
ORDER BY name_lc
LIMIT 25
```

-- Who entered and who left the VAT-cash register between two days: The register is republished in full every day, so the difference between two snapshots is the movement. Both sides prune to one day because snapshot_date leads the sort order.
```sql
ATTACH IF NOT EXISTS 'ducklake:https://data-directory.fsn1.your-objectstorage.com/catalog/catalog.ducklake' AS "datadirectory" (READ_ONLY);

WITH today AS (
  SELECT cui, name FROM datadirectory.anaf_company_register.vat_cash_register WHERE snapshot_date = DATE '2026-09-03'
), yesterday AS (
  SELECT cui FROM datadirectory.anaf_company_register.vat_cash_register WHERE snapshot_date = DATE '2026-09-02'
)
SELECT t.cui, t.name
FROM today t
LEFT JOIN yesterday y USING (cui)
WHERE y.cui IS NULL
```

## Live lake — DuckLake catalog with time travel

Attach the published catalog read-only over plain https. This works in native DuckDB AND in
duckdb-wasm in the browser — the reader catalog resolves its data files through public https
URLs, so no credentials and no backend are involved.

```sql
INSTALL ducklake; LOAD ducklake;
ATTACH 'ducklake:https://data-directory.fsn1.your-objectstorage.com/catalog/anaf-company-register/catalog.ducklake' AS anaf_company_register (READ_ONLY); SELECT * FROM anaf_company_register.main.companies LIMIT 5;
USE anaf_company_register;
```

- Latest catalog: https://data-directory.fsn1.your-objectstorage.com/catalog/anaf-company-register/catalog.ducklake
- This exact version: https://data-directory.fsn1.your-objectstorage.com/catalog/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/catalog.ducklake (sha256 86aea104c0d54051f43ece44445a1fe9e7bc45b3829172860dfa70a345048928)
- Written by DuckDB v1.5.5
- Time travel: this ingest is snapshot 13 — e.g. `SELECT * FROM anaf_company_register.companies AT (VERSION => 13)`

## Wholesale — S3 access

For bulk downloads, read the bucket prefix directly over S3 with httpfs:

```sql
INSTALL httpfs; LOAD httpfs;
CREATE SECRET hetzner (
  TYPE s3,
  ENDPOINT 'fsn1.your-objectstorage.com',
  URL_STYLE 'path',
  KEY_ID '<public-read-not-required>', SECRET ''
);
SELECT * FROM read_parquet('s3://data-directory/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/**/*.parquet');
```

## Schema

### companies
One row per Romanian taxpayer (CUI), carrying the identity fields ANAF republishes from the Trade Register: the ONRC registration number, the CAEN activity code, the legal and organisational form, the registered office, the competent tax office and the VAT / inactive status. Rows are upserted, so first_seen_date and last_seen_date widen over time while every other column reflects the most recent lookup. PERSONAL DATA WARNING: a large share of Romanian CUIs belong to PFA, II, IF and individual professionals (lawyers, doctors, notaries, authorised natural persons). For those, `name` IS a natural person's name and the registered office IS very often that person's home address. This table is published because Romanian law treats the trade-register record as public information, but anyone reusing it is processing personal data and owes the GDPR duties that come with it. The bank account (IBAN) ANAF also returns is deliberately not published here. A run refreshes one deterministic slice of the CUI universe, not all of it — see lookup_coverage for exactly which.
- 522K rows · 31 MB · write mode `upsert`
- Physically sorted by: `name_lc`
- Primary key: `cui`
- Text search columns: `name`
- Files: 1
  - https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/companies.parquet (522K rows)

Columns:
- `cui` VARCHAR NOT NULL — The taxpayer identification code (cod unic de înregistrare), as text without the "RO" prefix. Text rather than a number because a CUI is an identifier: it is written "RO14399840" when the holder is VAT-registered, is quoted with leading zeros on many official documents, and is never summed. Join key for vat_cash_register and vat_cash_events. (~502093 distinct)
- `name` TEXT NOT NULL — The registered name of the taxpayer, exactly as ANAF returns it (denumire). For a PFA or an individual professional this is a natural person's name.
- `name_lc` VARCHAR NOT NULL — name, lowercased and accent-folded (NFD, combining marks removed), so that a prefix search is a range on a sorted column and "Bucuresti" finds "București". This is the physical sort order of the table. (range: "\" alexandru iofciulescu - cabinet de avocat\"" … "„ tiril si asociatii ” - societate civila de avocati")
- `reg_com_number` VARCHAR — The Registrul Comerțului (Trade Register) registration number — the ONRC identifier this dataset exists for. ANAF emits it in two shapes and neither is rewritten here: the human-readable "J40/1234/2000" and the run-together "J2002000372404" (letter, year, six-digit sequence, two-digit county). Absent for taxpayers that are not registered with the Trade Register at all, such as public institutions and some professional forms.
- `caen_code` VARCHAR — The four-digit CAEN Rev. 2 code of the principal declared activity, as ANAF returns it (cod_CAEN). Not a label — join it to a CAEN nomenclature for the activity name.
- `legal_form` VARCHAR — The legal form (forma_juridica) in ANAF's own Romanian wording, e.g. "SOCIETATE COMERCIALĂ PE ACŢIUNI", "SOCIETATE CU RASPUNDERE LIMITATA", "PERSOANA FIZICA AUTORIZATA". Verbatim, diacritics and all, so it can be matched against other copies of ANAF data.
- `organisation_form` VARCHAR — The organisational form (forma_organizare): whether the taxpayer is a legal person, a natural person, or a form without legal personality.
- `ownership_form` VARCHAR — The ownership form (forma_de_proprietate): private domestic capital, private foreign capital, state ownership, and the mixtures ANAF distinguishes.
- `registration_status` VARCHAR — The registration status sentence ANAF returns verbatim (stare_inregistrare). It is prose, not a code, and it carries its own date inside it — "INREGISTRAT din data 29.08.2006", "RADIAT din data 12.03.2019". Kept unparsed because the wording is the source's own statement of the fact; registration_date holds the machine-readable date separately.
- `registration_date` DATE — The fiscal registration date (data_inregistrare) — when the taxpayer was entered in the fiscal register. A Europe/Bucharest calendar day: it is the day named by a Romanian administrative act, and ANAF publishes it with no time and no offset. Not necessarily the Trade Register incorporation date.
- `tax_office` VARCHAR — The competent tax administration (organFiscalCompetent) the taxpayer files with, in ANAF's own wording, e.g. "Administraţia Sector 2 a Finanţelor Publice".
- `address_full` TEXT — The single-line address ANAF prints for the taxpayer (date_generale.adresa) — usually the fiscal domicile, upper-cased, with no consistent internal structure. The parsed components of the REGISTERED OFFICE are in the county/locality/street columns below and may name a different place.
- `county` VARCHAR — County (județ) of the registered office, as ANAF names it (sdenumire_Judet). Bucharest is "MUNICIPIUL BUCUREŞTI".
- `county_code` VARCHAR — The county's numeric SIRUTA-style code in ANAF's own nomenclature (scod_Judet), as text because leading zeros are meaningful in it.
- `county_plate` VARCHAR — The two-letter vehicle-registration county code (scod_JudetAuto) — "B" for Bucharest, "CJ" for Cluj. The code most Romanian datasets key counties by.
- `locality` VARCHAR — Locality of the registered office (sdenumire_Localitate). For Bucharest this names the sector, e.g. "Sector 6 Mun. Bucureşti".
- `street` VARCHAR — Street name of the registered office (sdenumire_Strada), including the Romanian street-type abbreviation ANAF writes with it.
- `street_number` VARCHAR — Street number of the registered office (snumar_Strada). Text, because it is routinely "148A" or "12 BIS".
- `address_details` TEXT — The free-text remainder of the registered office (sdetalii_Adresa): building, staircase, floor, apartment, office. For a PFA this is frequently an apartment number in a home.
- `postal_code` VARCHAR — Postal code of the registered office (scod_Postal). Text: Romanian postal codes are six digits and may begin with a zero.
- `is_vat_registered` BOOLEAN — True when the taxpayer is registered for VAT purposes on the lookup date (inregistrare_scop_Tva.scpTVA) — i.e. when its CUI is correctly written with the "RO" prefix.
- `is_vat_cash_accounting` BOOLEAN — True when the taxpayer applies the VAT-cash-accounting regime (TVA la încasare) on the lookup date (inregistrare_RTVAI.statusTvaIncasare). The same fact the vat_cash_register table snapshots from the bulk file, reached the other way round.
- `is_inactive` BOOLEAN — True when the taxpayer is on ANAF's register of inactive taxpayers (stare_inactiv.statusInactivi) — a declared-inactive company whose invoices carry no deduction right for its counterparties.
- `is_split_vat` BOOLEAN — True when the taxpayer applies split VAT payment (inregistrare_SplitTVA.statusSplitTVA). The regime was made optional after 2020, so this is almost always false and is kept because ANAF still publishes it.
- `is_efactura_registered` BOOLEAN — True when the taxpayer is entered in the RO e-Factura register (date_generale.statusRO_e_Factura).
- `phone` VARCHAR — The contact telephone number ANAF holds for the taxpayer (date_generale.telefon), as a string. Blank for most taxpayers, and NULL here when blank. For a PFA it may be a personal number — treat it as personal data. ANAF also returns a fax number and an IBAN; neither is published here.
- `first_seen_date` DATE NOT NULL — The first snapshot day (UTC) on which this CUI was looked up successfully — a UTC day, because it is this platform's own run date rather than anything ANAF stated. Maintained by the framework: the upsert takes the earlier of the stored and incoming values, so it only ever moves backwards.
- `last_seen_date` DATE NOT NULL — The most recent snapshot day (UTC) on which this CUI was looked up successfully — a UTC day, because it is this platform's own run date. Because a run refreshes one slice of the CUI universe, a company being stale here means its slice has not come round yet, not that it has disappeared.
- `snapshot_date` DATE NOT NULL — The snapshot day (UTC) of the run that last wrote this row — the same date sent to ANAF as the lookup date, so every status column is the status AS OF this day.
- `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC).

### vat_cash_register
The daily snapshot of ANAF's Registrul persoanelor impozabile care aplică sistemul TVA la încasare — the register of taxpayers on the VAT-cash-accounting regime — one row per taxpayer per day, read from the agenti.txt file inside ultim_<yyyymmdd>.zip. On 2026-09-03 it listed 520,477 taxpayers. This is a real register in its own right, and it is NOT a list of all Romanian companies: only taxpayers who apply the cash-accounting regime are in it. Because a full snapshot is republished every day, comparing two days shows exactly who entered and who left.
- 3.7M rows · 68 MB · write mode `snapshot_history`
- Physically sorted by: `snapshot_date`, `cui`
- Primary key: `snapshot_date`, `cui`
- Text search columns: `name`
- Files: 1
  - https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/vat_cash_register.parquet (3.7M rows)

Columns:
- `snapshot_date` DATE NOT NULL — The register day (UTC) this snapshot is for. It is the date in the archive file name — ANAF publishes the file for day D on the afternoon of D-1. (range: "2026-09-04" … "2026-10-22") (~7 distinct)
- `cui` VARCHAR NOT NULL — The taxpayer identification code, verbatim from the file's cod_fiscal field. Joins to companies.cui. (range: "10000326" … "9999999986") (~502093 distinct)
- `name` TEXT NOT NULL — The taxpayer name, verbatim from the file's denumire field. ANAF declares it as nvarchar(250) and writes it without quoting, so a name containing "#" keeps it.
- `name_lc` VARCHAR NOT NULL — name, lowercased and accent-folded, so a prefix search over the register is a range predicate rather than a pattern match.
- `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC).

### vat_cash_events
The event history of the VAT-cash-accounting register: one row per register operation per daily snapshot, read from the istoric.txt file inside ultim_<yyyymmdd>.zip (958,093 rows on 2026-09-03). One event is a taxpayer entering the regime, leaving it, or having an earlier entry corrected, with the dates the operation applies from, was published and was processed. The column names are ANAF's own: the RTVAI application ANAF publishes alongside the register ships the schema of this file in its HSQLDB script (ISTORIC_TAB) and its loader SQL, so nothing here is inferred from the shape of the data.
- 6.7M rows · 52 MB · write mode `snapshot_history`
- Physically sorted by: `snapshot_date`, `cui`, `event_id`
- Primary key: `snapshot_date`, `event_id`
- Files: 1
  - https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/vat_cash_events.parquet (6.7M rows)

Columns:
- `snapshot_date` DATE NOT NULL — The register day (UTC) this snapshot is for, from the archive file name. The whole history is republished every day, so an event appears once per snapshot it survives in. (range: "2026-09-04" … "2026-10-22") (~7 distinct)
- `event_id` BIGINT NOT NULL — ANAF's own primary key for the register event (ISTORIC_TAB.ID). Stable across snapshots, which is what makes "what changed yesterday" an anti-join on this column. (range: "1" … "99999") (~943987 distinct)
- `cui` VARCHAR NOT NULL — The taxpayer identification code the event belongs to (cod_fiscal). Joins to companies.cui and vat_cash_register.cui. (range: "10000326" … "9999999986")
- `start_date` DATE — data_inceput — the Europe/Bucharest calendar day the operation takes effect from, i.e. the first day the taxpayer applies (or stops applying) the regime under this act. The source writes it as yyyymmdd with no time and no offset; it is a Romanian administrative date.
- `end_date` DATE — data_sfarsit — the Europe/Bucharest calendar day the taxpayer leaves the regime under this act. Empty in the source, and NULL here, for an entry that is still open.
- `published_date` DATE — data_publicare — the Europe/Bucharest calendar day the operation was published in the public register.
- `processed_date` DATE — data_prelucrare — the Europe/Bucharest calendar day ANAF processed the operation internally. Normally the day before publication.
- `operation_code` VARCHAR — tip_operatie — the one-character operation code, verbatim. ANAF publishes the column but not the code list, so the meanings below were confirmed by looking the same taxpayer up in ANAF's own v9 web service, which returns a tipActTvaInc label for the same act: "I" = Inregistrare (entered the regime), "D" = Radiere (removed from the regime), "E" = Indreptare eroare materiala (an earlier entry corrected). A fourth code, "S", occurs twice in 958,093 rows and the web service returns no label for it, so it is published as-is and deliberately not interpreted.
- `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC).

### lookup_coverage
One row per batch of CUIs sent to ANAF's per-CUI service, so the coverage of every run is a fact in the data rather than something a reader has to reconstruct from the calendar. A run refreshes one deterministic slice of the CUI universe (cui modulo `shards` equals `shard`), because ANAF permits one request a second and 500 CUIs per request; consecutive days take consecutive slices, so a daily schedule walks the whole universe once every `shards` days. This table is what lets a reader say "the companies rows for this slice are as of that day" — and, when ANAF did not answer, exactly which stretch of CUIs went unrefreshed and why: a batch whose failure_reason is not NULL was requested and never usably answered, so it produced no companies rows at all.
- 7,308 rows · 26 KB · write mode `snapshot_history`
- Physically sorted by: `snapshot_date`, `cui_from`
- Primary key: `snapshot_date`, `cui_from`, `cui_to`
- Files: 1
  - https://data-directory.fsn1.your-objectstorage.com/public/anaf-company-register/v/01M5H0M8XKYN3BWY4GC5WBT2SF/lookup_coverage.parquet (7,308 rows)

Columns:
- `snapshot_date` DATE NOT NULL — The snapshot day (UTC) of the run that made this batch. (range: "2026-09-04" … "2026-10-22") (~7 distinct)
- `source` VARCHAR NOT NULL — Where the CUIs in this batch came from: "register" when they were read from that day's VAT-cash register file, "range" when the run swept a numeric CUI interval directly.
- `shard` INTEGER NOT NULL — Which slice of the CUI universe this run covered — the value of cui modulo `shards` every CUI in the run satisfies. When the run was not given one explicitly it is derived from the snapshot date, so consecutive days cover consecutive slices.
- `shards` INTEGER NOT NULL — How many slices the CUI universe was divided into for this run. With the default of 30 and a daily schedule, every CUI is refreshed once a month.
- `cui_from` BIGINT NOT NULL — The smallest CUI in this batch, as a number. Numeric here — unlike companies.cui — because this column describes an interval of the CUI space rather than identifying a taxpayer. (range: "10029004" … "9957401") (~4390 distinct)
- `cui_to` BIGINT NOT NULL — The largest CUI in this batch, as a number. (~3995 distinct)
- `requested` INTEGER NOT NULL — How many CUIs the request carried. Never more than 500, which is ANAF's documented ceiling.
- `found` INTEGER NOT NULL — How many of them ANAF returned data for — the length of the response's `found` array, and the number of companies rows this batch produced. Zero when failure_reason is set, because a batch that was never usably answered returned nothing.
- `not_found` INTEGER NOT NULL — How many of them ANAF did not know — the length of the response's `notFound` array. A batch where this equals `requested` is answered with HTTP 404 by design, which is a normal empty result and not an error. Zero when failure_reason is set: an unanswered batch says nothing about whether ANAF knows those CUIs.
- `failure_reason` VARCHAR — NULL when ANAF answered this batch — the ordinary case, including the HTTP 404 that means "found is empty". Otherwise the plain-words reason the batch was never usably answered, naming the HTTP status, the content type and the first 200 characters of what came back: a maintenance or rate-limit page where JSON was promised, a 5xx the transport gave up retrying, a gateway error document. Those batches produced NO companies rows, so their CUIs still carry whatever last_seen_date an earlier run gave them — this column is how a reader tells "ANAF says nothing changed" apart from "ANAF was not reachable". A run in which more than half the batches failed, or twenty failed in a row, fails outright and publishes nothing, so a coverage table that exists is never mostly holes.
- `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC).


## Performance notes

- There are no indexes in a lakehouse. The physical sort order plus Parquet row-group min/max
  statistics ARE the index. Predicates on the leading sort columns prune whole row groups;
  everything else is a full column scan.
- `companies` prunes on `name_lc`.
- `vat_cash_register` prunes on `snapshot_date` → `cui`.
- `vat_cash_events` prunes on `snapshot_date` → `cui` → `event_id`.
- `lookup_coverage` prunes on `snapshot_date` → `cui_from`.
- `ILIKE '%needle%'` cannot prune: it decompresses that whole column. Prefer prefix predicates
  on the lowercased search companion columns where they exist.
- Every file URL under `/v/<ingestId>/` is immutable. Cache it as aggressively as you like.
- Files are never rewritten in place — a new ingest writes a new version path. Re-read the
  manifest to pick up updates rather than polling the file URLs.
- Pull only the columns you need. Parquet is columnar and the reader range-GETs what it reads.

## Do not

- Do not scrape https://data.bunnytech.app HTML. Every number on those pages comes from the manifest above.
- Do not hit the upstream source (https://static.anaf.ro/static/10/Anaf/TVA_incasare/modalitati_consultare_registrul_contribuabili.htm) in bulk. This mirror exists so you do not have to.
- Do not read DuckLake internal data files with a plain Parquet reader. They come with
  positional delete files, and ignoring those silently returns deleted rows. Use the ducklake
  extension, or use the published exports above.
- Do not republish without the attribution line, and do not imply endorsement.