# Identity, Tax & Invoice Processing (S5-S7)

## §5 — Identity from the Secure Element

The taxpayer identity is read directly from the SE certificate — nothing is entered by the operator.

<table id="bkmrk-fieldsource-in-the-c"><thead><tr><th>Field</th><th>Source in the certificate</th></tr></thead><tbody><tr><td>TIN</td><td>Certificate OID (tag-6)</td></tr><tr><td>UID</td><td>SERIALNUMBER (subject)</td></tr><tr><td>Company name</td><td>Subject `O`</td></tr><tr><td>Store / business unit</td><td>Subject `OU`</td></tr><tr><td>Address</td><td>Subject `STREET`</td></tr><tr><td>District</td><td>Subject `S`</td></tr><tr><td>TaxCore endpoint</td><td>Certificate extension (tag-5) — the environment URL</td></tr></tbody></table>

## §6 — Tax calculation &amp; rate management

Tax is calculated per item label against the active tax-rate group. Each tax category is applied by its type:

- **Tax on net** — added to the net amount.
- **Tax on total** — included within the price.
- **Per-quantity** — a fixed amount per unit.

Amounts are computed to **4 decimal places with half-round-up** and presented to 2 decimals on the response and journal. Invoices carrying a label outside the active group are rejected at validation (§17).

### Effective-dated groups

Tax-rate groups are installed by `SetTaxRates` (online) and can also be applied from the local-audit file. Future-dated groups take effect from their effective date; where dates coincide, the higher revision applies. The group in force at the invoice's referent date is used (current date for a normal sale; the original date for a copy/refund).

## §7 — Invoice processing pipeline

1. **Receive** — an invoice request arrives on the POS-to-SDC service as JSON.
2. **Validate** — structure, labels and amounts are checked; invalid requests are rejected with the proper error code (§16).
3. **Calculate** — taxes are computed on the active rates for the referent date (§6).
4. **Certificate check** — a proactive validity check ensures the SE certificate is valid for the current date before signing.
5. **Sign** — the request, SDC date/time and cached PIN are sent to the SE, which returns the signature, encrypted internal data and counters (§2).
6. **Journal** — a 40-column textual receipt is produced with the verification URL and QR code (§8).
7. **Store** — the encrypted audit package is committed to non-volatile storage *before* the response is returned (§9).
8. **Respond** — the fiscal result is returned to the POS.

Auditing runs on a background service that does not hold the card lock, so a POS sign is never queued behind a network operation.