> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sync2books.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Technology Architecture (TIS ↔ eTIMS)

> How Sync2Books operates as a Trader Invoicing System and transmits fiscal data to KRA eTIMS over OSCU — the architecture document submitted for third-party integrator certification.

This is the architecture behind the eTIMS pages in this section: how Sync2Books acts as a
**Trader Invoicing System (TIS)** and transmits fiscal data to **KRA eTIMS** over the **OSCU**
path. It is the same document submitted to KRA for third-party integrator certification, so it
describes the system as built rather than as planned — anything not yet implemented is confined
to its "Planned enhancements" section.

<a href="/assets/sync2books-TIS-Technology-Architecture-v2.pdf" download="sync2books-TIS-Technology-Architecture-v2.pdf">
  <Card title="Download the Technology Architecture document (PDF)" icon="download">
    Version 2.0 — 17 pages. Supersedes v1.0.
  </Card>
</a>

## What it covers

<CardGroup cols={2}>
  <Card title="System context" icon="diagram-project">
    The three ways fiscal data reaches KRA — dashboard, accounting platform, and the Compliance
    API — and why they all converge on one component that holds the OSCU credentials.
  </Card>

  <Card title="The integration surface" icon="plug">
    What an integrator actually works with: registering the business, getting an API key from the
    compliance dashboard, reference data, then sales, credit notes and receipts.
  </Card>

  <Card title="Credential custody" icon="key">
    Where the OSCU communication key, device id and SCU id live: one row per branch, held by the
    compliance service alone.
  </Card>

  <Card title="Integration sequence" icon="list-ol">
    Device initialisation → reference data → branch info → item registration → stock → sales and
    credit notes → purchases → receipt generation, each mapped to the OSCU operation it calls.
  </Card>

  <Card title="Receipt conformance" icon="receipt">
    The TIS receipt template: required fields, credit-note rules, COPY receipts, and QR
    verification against KRA's own receipt portal.
  </Card>

  <Card title="Environments" icon="server">
    Sandbox and production separation, and how each branch is tagged so submissions cannot cross.
  </Card>

  <Card title="Reliability" icon="rotate">
    Idempotency, KRA sequence-counter self-healing, and the audit trail kept for every
    submission.
  </Card>
</CardGroup>

## Who it's for

<Note>
  You do **not** need this document to integrate. Start with
  [eTIMS API Overview](/etims-overview) instead. The endpoints are in the [API reference](/etims-api-reference).
</Note>

It's written for reviewers and technical evaluators — KRA certification, a tax or security
audit, or a prospective partner's due diligence — who need to see how fiscal data reaches KRA
and how taxpayer credentials are held.

It describes the fiscalisation path and the interface you integrate against. It deliberately
leaves out our internal service topology and administrative interfaces: they aren't part of the
integration contract, and publishing them would widen the attack surface around taxpayers' KRA
device credentials without telling a reviewer anything useful.

## Source and versioning

The PDF is generated from a markdown source kept with the compliance service, so the document
and the code stay in the same review loop. It is rebuilt with:

```bash theme={null}
python3 scripts/build-architecture-pdf.py
```

Don't hand-edit the PDF — edit the markdown and rebuild, or the two drift apart.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.