e-Transport Excel Import: Declare UIT Codes in Bulk

An e-Transport Excel import turns a spreadsheet of shipments into separate declarations, each sent to ANAF and each receiving its own UIT code. The file uses three linked sheets — Transports, Goods, Documents — plus nomenclature sheets for partners, locations and vehicles. Before anything is sent, the values are cleaned where they can be cleaned safely, checked against ANAF’s official validation rules, and shown back to you with each error pointing at the cell it came from. Nothing leaves until you say so.

What is in the e-Transport Excel import template?

Three working sheets, linked by a transport reference you choose.

Two conventions in the headers are worth knowing before you start editing. The three working sheets use short technical column names, because several of them do not map onto one field: what “start location” means depends on the operation type, and the same column becomes a border crossing point, a customs office or a street address. The nomenclature sheets use the plain field names of the entity they feed, because there the mapping is one to one.

Row 1 of every sheet carries the instructions and row 2 carries the header. Data starts at row 3. Tools that assume the first row is the header will read the guidance text as column names — worth remembering if you generate the file from a script.

The template comes in Romanian, English, and a bilingual Romanian-English version for teams where the person exporting from the ERP and the person checking the file are not the same person. What the whole system asks for, and why these fields exist, is set out in the RO e-Transport overview.

How do rows become declarations?

By reference. Each Transports row is one declaration. Every Goods row and every Documents row naming the same reference is attached to it. So a file with 20 transports, 63 goods lines and 20 CMRs produces 20 declarations and 20 UIT codes, not 103 of anything.

That grouping is also how groupage works. One consignment, one UIT code — a truck with four consignments is four transports in the file, each with its own goods lines, not one transport with the goods of four customers piled onto it.

What gets fixed automatically, and what does not

The principle behind the import is one rule, stated once: repair everything that can be repaired safely, report the repair, and stop only where a value cannot be deduced or where the choice belongs to a person.

Fixed and reported:

• 840 kg in a weight cell becomes 840. Units typed into number cells are the most common export artefact of all.
• 8031010 becomes 08031010. Combined Nomenclature codes lose their leading zero the moment a spreadsheet treats them as numbers, and they have to be kept as text.
• buc becomes H87, kg becomes KGM. Unit names are matched to the codes the schema expects.
• GR becomes EL. The ANAF schema does not contain GR at all — Greece is EL.
• Stray spaces are trimmed. The schema’s text fields do not allow leading, trailing or doubled spaces, so a single space copied from a PDF invalidates the file.

Not fixed, and reported as an error:

• Net weight when only gross weight is present. It cannot be derived, and a guess here is a false declaration.
• A missing partner tax number, a missing tariff code, a missing quantity.
• An operation type that the rest of the row contradicts. Which of the two is wrong is a human decision.

Two values that are genuinely ambiguous

Some cells cannot be read with certainty, and pretending otherwise is how quiet errors get into declarations.

1,234 is one thousand two hundred and thirty-four in the United States and one point two three four in Romania. The Romanian convention is applied and the reading is flagged, so you can check it. One exception is safe: after a single leading 0, the separator is certainly decimal.

03/04/2026 is 3 April or 4 March depending on who typed it. Day-month-year is assumed and a warning is raised whenever both readings are possible. A wrong transport date is not a cosmetic error — it moves the declaration deadline and the code’s validity, both of which are covered in UIT code validity and deadlines.

The cure for both is upstream: export dates as ISO dates and numbers with an explicit decimal point, and neither ambiguity arises.

Validation happens before sending, not after

Every declaration built from the file is checked against ANAF’s official validation rules — the same Schematron rules ANAF applies — before a single message leaves. The errors are shown against the cell they came from, in Romanian and English, so “the tariff code on the third goods line of transport 4711” is a place in your spreadsheet, not a path in an XML file.

This ordering matters more than it sounds. ANAF returns a UIT code at upload, before it checks the content of the declaration, so a file sent unchecked comes back with 20 codes and a rejection arriving later. Checking first means the rejection never happens.

A worked example

A wholesaler exports 18 shipments of fruit on a Monday. The ERP produces one sheet, which is pasted into the Transports sheet of the template; the goods lines come from the same export.

• The tariff codes arrive as 8031010 because the ERP column is numeric. All 41 goods lines are repaired to 08031010 and listed as corrections.
• Nine weight cells read 840 kg. Cleaned to numbers, reported.
• Two rows have a gross weight and no net weight. Errors, both times, pointing at the exact cells. Corrected on screen from the packing lists, re-checked, clean.
• One row names Greece as GR. Corrected to EL.
• Eighteen declarations are sent. Eighteen UIT codes come back, each followed until its status is accepted.

Total time at the keyboard: the two net weights.

The library and the file stay separate

An application that declares from files also keeps a library of partners, locations, vehicles and goods for the on-screen form. The two are not synchronised, in either direction, and that is a design decision rather than a missing feature: a dictionary with two sources is a dictionary nobody can trust. Your file’s nomenclature sheets travel with your file; the library serves the form.

The one crossing is a bridge you ask for: a copy, run once, showing you code by code what would change before anything is written. It never overwrites an entry you did not tick, and it never deletes. Rows that would change are not pre-ticked, because a saved entry may hold something the file does not know — a corrected address, a verified tax number.

Where the standard advice fails

“Send everything, fix the rejections.” ANAF gives the code at upload and validates afterwards, so this produces a folder of codes with unknown standing. Rejections then have to be matched back to rows by hand.

“The file is fine, it opens in Excel.” Files that open perfectly still carry numeric tariff codes, invisible trailing spaces and dates in the wrong order. None of those are visible; all three invalidate a declaration.

“We will reuse last week’s file.” Reuse the structure, not the dates. A copied file with last week’s transport dates fails on the deadline, which is at most 3 calendar days before the declared start date and no later than the vehicle moving.

“Bigger batches are safer.” They are not, but they are cheaper. What makes a batch safe is validating it before sending and reading the corrections list, not its size. The one genuine limit is that each transport still has to obey its own deadline — see how to get a UIT code in Romania.

Sources: OUG 41/2022 on legislatie.just.ro; ANAF’s RO e-Transport guide (2025); technical information on mfinante.gov.ro.