Case study

Zentra

Tax filing automation for the Dominican Republic

The problem

Every month, accountants and companies in the Dominican Republic sit down and type invoice after invoice to assemble the 606 and 607 files the DGII requires. It's manual, repetitive and fragile work: one mistyped tax ID or one invalid receipt number gets the file rejected, and the whole thing has to be reviewed again — with the deadline already closing in.

Context

Zentra is my own product, not a commission. It came from seeing the same problem in three different profiles: the independent accountant handling a handful of companies, the accounting firm with a client portfolio, and the company with high document volume that needs a dedicated setup.

The solution

Tax dashboard with the state of the period
AI scanner for paper, PDFs and photos
606 report (purchases and expenses)
607 report (sales and income)
Tax ID and receipt-number validator
Official TXT file generator

Features

Reads invoices from thermal paper, PDFs and photos taken with a phone.
Automatic extraction of tax ID (RNC), receipt number (NCF), date, amount and VAT.
Validation of RNC and NCF with the Module 10 and Module 11 algorithms before anything is generated.
Review screen that shows the original document next to every extracted field.
Generation of the TXT file in the tax authority's official format.
Batch processing, so a whole period can be closed in one pass.

My role

Architecture and data modelBackend and APIInterface and user experienceAI model integrationContainerization and deployment

Technical decisions

The AI extracts, the person confirms

The system never accepts a value without someone seeing it. Every extracted field is shown next to the original document, because a mistake in a tax filing isn't fixed with an undo button. The AI saves the typing, not the responsibility.

Validating tax IDs inside the system

I implemented the Module 10 and Module 11 checks inside the product instead of letting the error surface when the file is uploaded. That's the difference between fixing it at your desk and having the tax authority reject your submission.

PostgreSQL for the relationships, not for fashion

A receipt belongs to a company, a period and a classification, and those relationships have to stay consistent or the generated file won't add up. That's exactly the case for a relational database.

Stack

Vue 3NestJSPostgreSQLGoogle GeminiDocker

View the code

Difficulties

The real input isn't clean PDFs: it's faded thermal paper and crooked phone photos. The scanner had to treat that as the normal case, not the exception.
[PENDING: real technical difficulties worth telling — what was hardest and how you solved it]

Result

The system replaces manual data entry for the entire 606/607 cycle: from a photo of the invoice to the TXT file ready to upload, with nothing transcribed by hand.
Tax ID and receipt-number errors are caught before the file is generated, not after it's rejected.
It's in production and can be tried in the live demo.

Demo

The best proof is the system running. It's live:

Open the demo