The problem
Electronic invoicing in Costa Rica is mandatory: regulation DGT-R-48-2016 from the Ministry of Finance requires every taxpayer to issue digitally signed electronic receipts and transmit them to the government platform in real time. Most POS solutions available on the market are generic or foreign-built, with poor local integrations and licensing costs that are out of reach for mid-sized businesses. The goal was to build a complete suite — from the cash register to the API — designed from the ground up around Costa Rican regulations.
The solution
POS Tree Codes is a three-layer hybrid suite. The primary application is a Java 21 Swing desktop client designed for the main point of sale: it handles sales, cash reconciliation, inventory management, and electronic invoice generation with digital signatures. For additional sales points — waitstaff, warehouses, mobile stations — there is a PHP-based WebPOS, lighter in scope, that consumes the same REST API. The core of the system is a REST API built with Spring Boot 3.5 that centralizes business logic, DGT communication, and data persistence in MySQL 8.
Architecture
The database has 57 tables covering everything from the product catalog and tiered pricing to the electronic document history and communication logs with the tax authority. The electronic invoicing module handles XML generation according to the official XSD schema, digital signing with a PKCS#12 certificate, and asynchronous submission to the DGT API with automatic retries on connectivity failures. The Swing client contains over 250 Java classes organized into presentation, service, and repository layers, and is distributed as a native Windows executable with an installer. Authentication between the WebPOS and the API uses JWT with token rotation, while the desktop client maintains an encrypted persistent session stored locally.
System shape
The project had to behave like one product across three very different surfaces:
- a desktop POS for the main checkout workflow
- a lighter WebPOS for auxiliary sales points
- a central REST API that holds the business rules and tax integration
That split was intentional. The cashier desk needed speed, keyboard-heavy workflows and local continuity. Secondary points needed lighter access from the browser. The API became the shared operational core so pricing, inventory and invoicing logic would not drift between clients.
Why this was more than a billing feature
Electronic invoicing sounds like a compliance checkbox, but in practice it touches almost every part of the system:
- the sale cannot close without valid tax data
- the XML must match the official schema exactly
- signatures must be valid and traceable
- connectivity failures cannot block the business permanently
That means the invoicing module is not an add-on. It defines the reliability standard for the whole product.
Outcome
The final result is a suite that feels grounded in local operational reality instead of adapted from a generic foreign template. The desktop app handles the heavy daily workflow, the WebPOS extends the system to additional stations, and the backend turns Costa Rican compliance into a repeatable process rather than a fragile manual ritual.
What makes the project valuable is not just that it issues invoices. It is that it connects sales, inventory, authentication and tax communication into a coherent system businesses can actually run on top of.
