Skip to main content

The DGII test set: the stage that stretches every certification

It is where nearly everyone gets stuck and the worst documented part of the process. What gets tested, in which environment, and why most rejections are data problems rather than software problems.

7 min read

Between applying for Emisor Electrónico status and being authorised to issue in production sits a stage that is rarely explained well: the test set. It is a battery of use cases the DGII requires you to pass in its certification environment, and it runs past thirty scenarios.

What the certification environment is

It is an environment separate from production, where the receipts you issue carry no fiscal effect. Its purpose is to demonstrate that your system generates the right XML, signs it correctly, transmits it and can interpret the response. Nothing issued there counts as an invoice.

That separation is useful and worth exploiting: it is the only moment where you can get things wrong at no cost. Moving to production without having deliberately provoked errors in certification means discovering them with a client in front of you.

What gets tested

  • Issuance of the e-CF types that match your operation.
  • Credit and debit notes, which are almost always tested less than they are used.
  • The electronic consumer-invoice summaries.
  • Receiving and processing DGII responses, rejections included.
  • Cancellation scenarios and e-NCF sequences.

Where most companies fail

The pattern repeats: people assume it is a software problem and it is almost always a data problem. The system produces technically valid XML carrying information that does not add up.

  • Client RNC values stored incorrectly or in the wrong format.
  • Receipt types assigned to the wrong client profile.
  • Amounts and ITBIS with rounding differences between the system and the validator.
  • A digital certificate badly installed, expired, or with the P12 passphrase misplaced.
  • e-NCF sequences misconfigured or exhausted mid-test.
  • Required fields left empty because nobody ever filled them in real operations.

That last one is the most revealing part of the process: the test set does not audit your software, it audits the quality of your master data. A company with a clean client catalogue passes quickly. One carrying years of incomplete records finds out here.

How to shorten it

  1. Clean the master data first: RNC values, legal names, client types. It is work you have to do anyway, and doing it first avoids repeating cases.
  2. Define which receipt types you genuinely need by looking at last year's invoices rather than the full list.
  3. Test the error paths on purpose, not just the happy path. A rejection understood in certification is one fewer incident in production.
  4. Document every approved case with its response. When something fails in production, that is your reference.
  5. Configure contingency before go-live: queue and retry, do not stop invoicing.

The test set is one stage of becoming an electronic issuer; the rest of the path is there.

Frequently asked questions

Every case matching the receipt types you will issue. That is why defining that scope upfront saves time: each declared type drags its own cases along.

You correct it and resubmit. There is no penalty for failing in certification — that is what the environment is for. What it costs is round-trip time, which is where projects arriving tight against their deadline slip.

It depends on the setup. The cases require understanding both the tax requirement and the behaviour of the issuing system, so it usually works best with two people: the accountant validates that the receipt is correct, and whoever knows the system fixes what validation returns.

The approval forms part of your authorisation file. If you change issuing route or provider, it is reasonable to expect re-validation, because what was certified was a specific configuration. Confirm it with the DGII for your case.

Stuck in the test set?

This is the stage we support most. We review the failing cases, fix the cause — usually in the data, not the code — and resubmit until approval.

See our e-CF electronic invoicing service

Keep reading