DUIMP: the Single Import Declaration.
What it is, who is required and how to migrate from the DI in the Single Portal.

What the DUIMP is — and what it is for

DUIMP stands for Single Import Declaration. It is the single electronic document, registered in the Single Foreign Trade Portal, that consolidates in one place the customs, administrative, commercial, financial, tax and fiscal information of an import operation. This is the official definition of the Federal Revenue Service (Receita Federal) — and it is what structurally sets it apart from the earlier model, in which the data were scattered across several documents (DI, LI, payment receipts) and across distinct systems.

It serves to declare the import in an integrated manner: to identify the importer and the cargo, to state the goods and the tariff classification, to calculate and collect the taxes, to comply with the administrative treatment of the licensing agencies and to submit the operation to customs verification — all from a single record. In practice, the DUIMP is the instrument of the New Import Process (NPI), the re-engineering of Brazilian customs clearance conducted by the Federal Revenue Service and by Secex within the Single Portal Programme.

The normative matrix

The DUIMP was not born of a single rule — it is the result of a layered construction:

• Decree 8.229/2014 established the Single Foreign Trade Portal Programme, amending Decree 660/1992 (which had created Siscomex) — the institutional basis of the project.
• IN SRF 680/2006 governs import customs clearance and came to admit processing both by DI (Siscomex Importação) and by DUIMP (Single Portal) — a scenario added to art. 2, §2-A by IN RFB 1.833/2018 (25/09/2018).
• Coana Ordinance 165/2024 (19/09/2024) is the operational act: it addresses the advance registration of the DUIMP before the cargo arrives (art. 3), the automatic debit of taxes from a registered account (art. 6), the verification channels (art. 7) and the fulfilment of ICMS obligations through the PCCE module (art. 11) — and it repealed the former Coana Ordinance 77/2018, which governed the pilot.
• IN RFB 2.226/2024 (27/09/2024) modernized IN 680: it created the partial clearance of the declaration (art. 48, §11-A), allowed more than one declaration for the same bill of lading in specific situations (art. 67) and replaced the data annexes of the DI and the DUIMP.

Where it came from

The DUIMP went into production on 1 October 2018, in a pilot restricted to companies certified as Authorized Economic Operator (OEA), governed by Coana Ordinance 77/2018. For years it coexisted with the DI in a dual model — the company could choose. The turning point came in 2024-2026, when the Federal Revenue Service began to make the DUIMP mandatory by stages, switching off the DI mode by mode. Today the dual model is dying out: in the operations already migrated, the DUIMP ceased to be an option and became the only path.

What is the difference between the DI and the DUIMP

The essential difference is one of architecture. The DI (Import Declaration) is the old model, processed in Siscomex Importação: there, the operation depends on several documents and systems — the DI itself, the Import Licence (LI) for administrative control, separate payment receipts — and the goods are declared repetitively on each import. The DUIMP is the Single Portal model: a single record that absorbs the role of the DI and the LI, calculates and debits the taxes in a centralized way and relies on a reusable product catalogue, in which the goods are registered once and reused in the following operations.

There are two swaps of parts that summarize the migration. In administrative control, the LI (the DI world) gives way to the LPCO — Licences, Permits, Certificates and Other documents — in the DUIMP world; it is the LPCO that carries the approvals of agencies such as Anvisa, MAPA, Inmetro and ANP. In payment, the one-off collection gives way to the PCCE — Centralized Foreign Trade Payment, with automatic debit of the federal taxes at the moment the DUIMP is registered and treatment of the ICMS in the same module.

There is a practical consequence that often catches those who hesitate in the transition: registering a DI in an operation that has already become mandatory in DUIMP results in the cancellation of the DI by the customs authority. The official DI-to-DUIMP Migration page is explicit on this point and refers to the Single Portal Simulator to check, by type of operation, whether the DI has already been switched off. It is not a matter of preference: once the mode is switched off, the DI simply ceases to be a valid path.

Who is required to use the DUIMP today

The DUIMP requirement is neither general nor uniform — it advances by stages, defined by transport mode (maritime, air, road, rail), by type of operation and by licensing agency. The golden rule, therefore, is not to memorize a date: it is to consult the official Single Portal Simulator, which tells you, for each operation, whether the DI has already been switched off and whether the DUIMP (and the LPCO) are already mandatory.

As of this date (July 2026), the consolidated picture is as follows: the DUIMP is already mandatory for the bulk of the maritime and air modes, with or without licensing — the result of the shutdowns of 22 April 2026 (maritime with no specific legal ground) and 27 April 2026 (air, plus the approvals of Anvisa, MAPA, CNEN, Inmetro and ANP, in addition to Drawback Exemption and Repetro in RJ). Before that, throughout 2025 and the start of 2026, specific operations were being migrated — Repetro, Recof, Drawback Suspension, auto parts, bonded warehouse —, in a roadmap that the Federal Revenue Service executed milestone by milestone.

What still runs on the DI

A relevant set of operations remains on the DI, being outside the stages already switched off (impossibilities of version 22 of the schedule): imports with Limited Radar; the Manaus Free Trade Zone, Free Trade Areas regimes and operations via SIAFI; the road and rail modes; cargo on own account and own means; imports by public bodies (planned for a future stage); Mantra; bulk to be amended; ANEEL and Suframa approvals; cigarettes; and the duty-free shop of the air mode and non-regular flights — these until 31/08/2026.

The DUIMP product catalogue — the heart of the new model

If there is one part that sums up the change of logic of the DUIMP, it is the product catalogue. Under the official rule, “to carry out an import operation with a DUIMP, it is mandatory that a DUIMP item corresponds to a Catalogue item of the company”. The goods cease to be re-declared from scratch on each import: they are registered once, with their technical and fiscal attributes, and reused in the following operations. This is what allows fast registration and consistency of classification over time.

Linked to the root CNPJ

The point that raises the most doubt — and operational error — is the ownership of the catalogue. Each product is linked to the root CNPJ (the first 8 digits) of the company, and not to the branch. This means that the catalogue is shareable among the branches (14 digits) of the same company, but not among distinct companies. Each product receives a sequential code, starting at 0000000001. When the goods are filled in directly on the DUIMP, the system already automatically generates the corresponding record in the catalogue.

Attributes: where the risk lives

Each product in the catalogue carries attributes — technical characteristics required by NCM, created in the Attributes Register at the request of the licensing agencies or of the Federal Revenue Service itself. They have defined types (boolean, date, static list, number and text) and can be conditioned, multi-valued or composite. The relation between attributes and NCM is updated daily, published in XML/JSON; the product Denomination admits up to 100 characters and the Description Complement, up to 3,700. Filling in the wrong attribute is not a detail: because it forms part of the fiscal definition of the goods, an inconsistent attribute speaks directly to the tariff classification (NCM) and to the administrative treatment — and that is where divergences between the catalogue and the DUIMP arise.

The product life cycle

Two fine mechanics are worth knowing. The anti-duplication lock blocks the registration of an identical product — both on screen and via the API — but only issues a warning when the product is similar, leaving the decision to the operator. And the ex officio deactivation of a product occurs in three scenarios: when a new mandatory attribute linked to the NCM arises, when a mandatory conditioned attribute applies, or when a domain value stated in the product is deleted. Not deactivating the product, on the other hand, are the creation of an optional attribute, the deletion of attributes, the expansion of a list or the change/linking of a Foreign Operator.

Foreign operator: it is the country of origin that is mandatory

Linked to the catalogue is the Foreign Operator (the manufacturer/exporter abroad), also versionable — it admits Generate New Version, Amend, retroactive version and Deactivate (which unlinks all the products associated with it). Here lies a common confusion worth clearing up: the system admits an unknown manufacturer, but the country of origin is always mandatory. The TIN (the tax identification number of the operator abroad), by contrast, is optional — although the Federal Revenue Service itself stresses that filling it in is “of the utmost importance”, being a key to several benefits. In short: country of origin, mandatory; TIN, optional yet recommended.

The six DUIMP tabs — and where the taxes sit

Filling in the DUIMP is organized into six tabs in the Single Portal. It is common to see mistaken lists out there — including ones treating “Taxes” as a top-level tab —, but the official structure of the manual is as follows: Identification, Cargo, Documents, Item, Administrative Treatment and Summary. The taxes do not form a tab of their own: the item information is split into the sub-tabs Goods and Taxes, within the Item tab.

How the taxes enter the calculation

In the Taxes sub-tab of each item, the system calculates the federal import taxes — Import Duty (II), IPI, PIS/Pasep-Import and Cofins-Import — from the goods (NCM) and the declared valuation. The collection is not one-off: the federal taxes are automatically debited, at the DUIMP registration, from the accounts registered in the PCCE (Centralized Payment). Add to them the Siscomex Usage Fee, also debited via PCCE — since Jun/2021 (ME Ordinance 4.131/2021), BRL 115.67 per declaration plus BRL 38.56 per addition, an amount subject to staggered reductions as the number of additions rises.

The ICMS has its own track: it is declared in the PCCE (an obligation set out in Coana Ordinance 165/2024, art. 11), in the Importação >> Pagamento Centralizado >> ICMS menu, with the release of the cargo conditioned on the Sefaz signal in the module. The automatic debit of the ICMS is planned for future versions of the system — today the integration with the state treasuries advances state by state.

How to register a DUIMP — step by step

Registering a DUIMP does not begin on the declaration screen: it begins with the prerequisites. The Preparation Manual is explicit in requiring a qualification other than limited — that is, whoever only holds Limited Radar still operates on the DI. With the prerequisites in order, the DUIMP is born in version 0000 when it is saved and moves to 0001 when it is registered. The path is this:

1. Radar (Siscomex) qualification and representation. Qualify the company to operate in foreign trade in a mode other than limited, activate the Electronic Tax Domicile (DTE) and define the representatives in the Register of Intervening Parties (the Manager profile is granted by the legal representative).
2. Register the Foreign Operator and the Product Catalogue. Register the manufacturer/exporter — with country of origin mandatory (TIN optional, but recommended) — and register each item of goods in the catalogue, linked to the root CNPJ, with the correct NCM and attributes.
3. Configure the PCCE accounts. Register at least one authorized bank account in the Centralized Payment (menu Pagamento Centralizado >> Contas Bancárias Autorizadas), with an order of priority — without an authorized account, registration is impossible.
4. Arrange the LPCO and the administrative treatment. Check in the Simulator the applicable approvals and arrange the LPCO of the agencies (Anvisa, MAPA, Inmetro, ANP and the like) before registration.
5. Fill in the six tabs and run the Diagnosis. Complete Identification, Cargo, Documents, Item (Goods and Taxes), Administrative Treatment and Summary; the Diagnosis points out blocking errors (red) and non-blocking ones (yellow). Declarations with more than 1,000 items only by API.
6. Register and follow the verification. At registration, the federal taxes and the Siscomex Fee are automatically debited in the PCCE; declare the ICMS in its own module; the operation is distributed across the green, yellow, red or grey channels (Coana Ordinance 165/2024, art. 7) up to clearance.

A note on amendment: the DUIMP is versionable — each amendment generates a new version, and the active version is always the latest. The Amend DUIMP manual organizes the flow into Introduction, Draft the request, Diagnosis/Registration and Version comparison, allowing you to follow exactly what changed between one version and another.

The modules that orbit the DUIMP

The DUIMP is not an isolated form — it is the convergence point of several Single Portal modules, and knowing them avoids the sense of a labyrinth:

The DI migration schedule — a moving target

The migration from the DI to the DUIMP is the backdrop to everything we have seen so far — and it must be faced for what it is: a schedule that changes. The Federal Revenue Service periodically publishes and revises an official spreadsheet (on the date of this analysis, version 22, of 21/05/2026), and the milestones have already been postponed more than once. On 20/03/2026, Siscomex Importação Communication 020/2026 postponed shutdowns from 23/03 to 22/04 and from 30/03 to 27/04/2026 “to ensure greater safety, operational stability and predictability”. No date here should be treated as immutable.

What has already been switched off

Throughout 2025 and the start of 2026, the Federal Revenue Service executed a sequence of shutdowns by type of operation: November/2025 (Temporary Admission), December/2025 (Repetro rescheduled), January/2026 (Recof in SP, Drawback Suspension, auto parts), February/2026 (operations with no specific legal ground, except SP/RJ; auto parts in CE; imports by the Army, Ibama and the Ministry of Defence) and the close of 22 and 27 April 2026, which consolidated the bulk of the maritime and air modes.

What is still to come

It is worth clearing up a frequent misunderstanding: it is not correct to say that the legacy system “switches off entirely” in December 2026. The final block of 01/12/2026 closes the road, rail, Limited Radar and special deposit stage — but the imports by the public administration (Group 1 of the Legal Nature Table) remain outside the published schedule, with migration planned for a future stage. The legacy does not die entirely in December; it shrinks to a residue planned for later.

For specific operations, the transition gained bridges: Siscomex Importação Notice 033/2026 (28/04/2026) admitted, for example, an exceptional DI for consumption of bonded cargo via DUIMP with Drawback Exemption, in addition to the transfer to Drawback Suspension by DUIMP — with an official algorithm (module 11) to convert the DUIMP number into the DI format when needed. These are exceptions that confirm the rule: the course is the DUIMP, and the bridges exist so as not to block those who are midway.

What blocks the operation — and how to prepare

The migration to the DUIMP is, above all, a data project. Whoever treats the turn as a mere change of screen discovers, on the first registration, that the system is unforgiving of inconsistency. The most recurring blocking triggers are known:

• Poorly built catalogue: vague attributes, lack of standardization among branches and incorrect NCM — errors that propagate because the product is reused.
• Catalogue × DUIMP inconsistency: the declared item does not match the catalogue item — and the DUIMP requires the correspondence.
• LI registered after the deadline: in an already migrated operation, the system identifies the licence as out of time.
• A DI in an already switched-off operation: trying to register a DI where the DUIMP has become mandatory leads to the cancellation of the DI by the tax authority.

The reckoning with the ERP

For high-volume importers, the DUIMP is not operated manually. The Single Portal public APIs allow registering, amending and querying the DUIMP and the Catalogue directly from the company’s ERP (documentation at docs.portalunico.siscomex.gov.br), and declarations with more than 1,000 items can only be registered by API. Market platforms — TOTVS, Thomson Reuters, Conexos, Logcomex, among others — offer ready connectors. The decision to integrate is not IT’s alone: it is one of tax governance, because it is well-done integration that ensures the catalogue data, the NCM and the attributes reach the declaration consistently.

Why this is a legal matter, not merely an operational one

There is a temptation to treat the DUIMP as a customs broker’s problem. That is a mistake. The attribute filled in the catalogue defines the goods for fiscal purposes — and an inconsistent attribute speaks to the tariff classification, to the administrative treatment and, at the end, to the risk of assessment. The valuation declared in the Taxes sub-tab feeds the calculation base of the II and the IPI and, in operations with related parties, dialogues with customs valuation and transfer pricing. The DUIMP, in short, is where foreign trade meets tax law — and where consistency between the two planes ceases to be a recommendation and becomes a requirement of the system.

How the firm acts — from diagnosis to migration

Requirement diagnosis

The TaxUp team’s starting point is the question that precedes any system: is your operation already required to use the DUIMP? The diagnosis cross-checks mode, type of operation and licensing agency against the Single Portal Simulator and the version in force of the schedule — because, it being a moving target, today’s answer is not necessarily tomorrow’s. From that map comes the migration timetable of each product line and of each mode.

Structuring the catalogue and the registrations

The most labour-intensive front — and the one that most prevents assessment — is the construction of the product catalogue: definition of the correct NCM, consistent filling of the attributes per product, standardization among branches (all under the same root CNPJ) and registration of the foreign operator with country of origin. In parallel, the configuration of the PCCE accounts and the survey of the applicable LPCO. It is here that the catalogue × DUIMP inconsistency is eliminated before the first registration, not after the blocking.

Registration, amendment and litigation

In day-to-day work, the task is one of governance: a registration routine across the six tabs with a clean diagnosis, management of amendments by version and monitoring of the verification channels up to clearance. When a divergence arises — of classification, of valuation or of administrative treatment —, the firm conducts the technical defence, from the challenge at verification to the CARF, sustaining the consistency of the declared data.

Migration and integration plan

For high-volume importers, the structural decision of this window is the DI-to-DUIMP migration plan before the shutdown of the respective mode: sequencing by product line, integration of the ERP with the Single Portal APIs and training of the foreign trade and tax teams. Whoever treats the DUIMP as a change of screen arrives late; whoever treats it as a data and compliance project gets through the turn without blocking the operation. The Customs Law pillar gathers the neighbouring parts of this transition — from Radar/Siscomex to the Ex-tariff and to customs clearance.