# Country Capabilities

Choose a country below for its external regimes, responsibilities, exact field
mapping, and copyable payload fragments.

Capability is not legal certification
These contracts define what the receipt engine can represent and preserve.
Cheqi does not determine whether a regime applies or whether the supplied data
is legally sufficient for a particular transaction.

Example values are illustrative
Rates, amounts, identifiers, wording, and authority values in the examples
demonstrate placement only. Always use the values produced by your current tax,
POS, fiscal-device, or authority integration.

## Where generation happens

The merchant does not send plaintext receipt contents to Cheqi:

1. The merchant SDK encrypts the same `ReceiptPayload` independently for every
matched owner device.
2. Each owner device decrypts its copy, joins it in memory with server-known
supplier, customer, payment, and store context, and runs the shared Rust
engine locally.
3. Every owner device stores its own CHEQI receipt.
4. Exactly one leased owner device also generates the formats currently
accepted by downstream third parties.
5. That device builds and encrypts one document-bundle envelope per third
party. The backend receives ciphertext, format names, generator/envelope
versions, and final hashes—never plaintext CHEQI or UBL documents.


Generating a missing UBL document from CHEQI later is a separate wallet export
operation. It runs against CHEQI JSON stored locally on the device, not
plaintext stored by the Cheqi backend.

## Country index

| Country | External regimes | What Cheqi can represent |
|  --- | --- | --- |
| [Austria](/countries/at) (`AT`) | `AT_RKSV` | RKSV register, sequence, signature, certificate/device, and referenced QR evidence |
| [Belgium](/countries/be) (`BE`) | `BE_GKS`, `BE_GKS_2` | Canonical ordinary retail plus legacy GKS and GKS 2.0 POS/FDM evidence |
| [Canada](/countries/ca) (`CA`) | None | HST, GST-only, GST+PST, and GST+QST variants with optional region attribution |
| [Switzerland](/countries/ch) (`CH`) | None | Canonical UID/VAT and recipient context, plus optional VAT-included presentation |
| [Germany](/countries/de) (`DE`) | `DE_KASSENSICHV` | TSE transaction, register, serial, signature, payment split, and referenced QR evidence |
| [Denmark](/countries/dk) (`DK`) | `DK_DIGITAL_SALES` | Canonical retail plus digital-sales journal/signature evidence |
| [Estonia](/countries/ee) (`EE`) | None | Ordinary, exempt, and exact special-scheme wording variants |
| [Spain](/countries/es) (`ES`) | `ES_SIF`, `ES_VERIFACTU` | SIF and system-selected VERI*FACTU evidence |
| [Finland](/countries/fi) (`FI`) | None | Canonical electronic cash/card receipts and VAT itemization |
| [France](/countries/fr) (`FR`) | `FR_CERTIFIED_CASH_SYSTEM` | Canonical ordinary retail plus secure cash-system and certificate/attestation evidence |
| [United Kingdom](/countries/gb) (`GB`) | None | Canonical retail VAT and full VAT invoices; `UK` input normalizes to `GB` |
| [Greece](/countries/gr) (`GR`) | `GR_MYDATA` | myDATA classification, MARK/UID, provider, URL, and referenced QR evidence |
| [Ireland](/countries/ie) (`IE`) | None | Canonical invoices plus optional treatment, wording, and second-currency tax data |
| [Iceland](/countries/is) (`IS`) | None | Canonical consumer/business identity and optional VAT-included presentation |
| [Italy](/countries/it) (`IT`) | `IT_DOCUMENTO_COMMERCIALE` | RT, transmission, verification, optional lottery, and referenced QR evidence |
| [Netherlands](/countries/nl) (`NL`) | None | Canonical retail receipts and full or simplified UBL invoices |
| [Norway](/countries/no) (`NO`) | `NO_SALES_RECEIPT` | Cash/card sales, returns, corrections, POS, and terminal references |
| [Poland](/countries/pl) (`PL`) | `PL_FISCAL_RECEIPT` | Fiscal receipt/correction, register evidence, logo, signature/hash, and optional QR |
| [Portugal](/countries/pt) (`PT`) | `PT_AT` | Receipt, invoice, and credit-note ATCUD/hash/signature/QR variants |
| [Sweden](/countries/se) (`SE`) | `SE_CASH_REGISTER` | Sales, returns/corrections, and training-copy variants |
| [United States](/countries/us) (`US`) | None | State/local extension data for all 50 states and DC |


## Country selection

Only create `jurisdictionalData` when the selected country page identifies
information without a canonical field. When you create it, set `countryCode`
explicitly. The engine still supports supplier-country fallback for
compatibility:

1. Explicit `jurisdictionalData.countryCode` wins.
2. Otherwise, the supplier address country is used.
3. If neither exists, the engine does not invent a country.


The engine does not determine whether an external regime applies. Your
integration must keep the explicit country, selected regime, and legal supplier
consistent.

## Shared request rules

- Populate the normal receipt and server-known generation context first.
- Never duplicate a canonical receipt, party, payment, tax, identifier, date,
or barcode value in `additionalFields`.
- Use a direct `ReceiptPayload`; `jurisdictionalData` and `barcodes` are
top-level receipt fields.
- When a country page requires an external regime, set `regime` and an explicit
`regimeVersion`.
- Complete external authority, device, signing, or certified-software work
before final receipt generation.
- Use `FISCALIZED` only after that operation succeeds.
- Never submit a final receipt with `PENDING` or `FAILED`.
- Put machine-readable payloads in top-level `barcodes[]`; country fields may
reference them but do not contain barcode objects.
- Preserve identifiers, signatures, hashes, legal text, and QR payloads
exactly as produced.
- Add a country field only when the country page confirms that the canonical
contract has no field for that value.


See [Supplying Jurisdiction Data](/countries/jurisdictional-data) for the shared schema.