Skip to main content
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.

Download the Technology Architecture document (PDF)

Version 2.0 — 17 pages. Supersedes v1.0.

​
What it covers

System context

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.

The integration surface

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.

Credential custody

Where the OSCU communication key, device id and SCU id live: one row per branch, held by the compliance service alone.

Integration sequence

Device initialisation → reference data → branch info → item registration → stock → sales and credit notes → purchases → receipt generation, each mapped to the OSCU operation it calls.

Receipt conformance

The TIS receipt template: required fields, credit-note rules, COPY receipts, and QR verification against KRA’s own receipt portal.

Environments

Sandbox and production separation, and how each branch is tagged so submissions cannot cross.

Reliability

Idempotency, KRA sequence-counter self-healing, and the audit trail kept for every submission.

​
Who it’s for

You do not need this document to integrate. Start with eTIMS API Overview instead. The endpoints are in the API reference.
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:
Don’t hand-edit the PDF — edit the markdown and rebuild, or the two drift apart.