Introduction Entersoft Business Solution offers a complete integration with the RO e-Factura system from ANAF, via the cloud services platform Socrate Business Services, SBS eFactura. The person who needs to enter the connection data for setting the authentication to ANAF will need to have the ANAF authentication token for its digital signature with him in order to successfully complete the process.
Overview It is possible to send the invoice content with a special type of file (xml) to ANAF.
Sending invoices is mandatory, starting 1.07. 2022, for the following transactions:
B2G (business-to-government) transactions.
B2B (business-to-business) transactions containing at least one ‘high risk’ element.
B2C (business-to-consumer) transactions with holiday vouchers payment method.
Attention: As of January 1, 2024, the e-Factura system becomes mandatory for all VAT-registered companies in Romania and as of January 1, 2025, all B2C transactions must be sent to the e-Factura system.
Introduction The legislative basis for this implementation is OUG 41/2022, amended by OUG 115/2023. The Ministry of Public Finance, through ANAF, has made available a guide that can be found here.
Implementing e-Transport requires the following steps:
Upgrade to the latest version of EBS (at least 5.8.0-1).
SaaS agreement based on the number of operations (documents).
{class=“children children-type-tree children-sort-weight”}
Subsections of ANAF Integrations
Authentication
1. Introduction
Entersoft Business Solution offers a complete integration with the RO e-Factura system from ANAF, via the cloud services platform Socrate Business Services, SBS eFactura. The person who needs to enter the connection data for setting the authentication to ANAF will need to have the ANAF authentication token for its digital signature with him in order to successfully complete the process.
As this is an additional SaaS service, it must be purchased in advance, via Entersoft Cloud Store. Access data (API keys) will be registered in
Configuration & Tools > Customize… > General > Company Parameters under the ANAF services and declarations category.
2. Authentication procedure
To set or modify your ANAF login data, go to the menu Configuration & Tools > Communication system > ANAF - Accounting authorization… then choose the Authorize for e-Factura button from the dialog that opens.
You will be redirected to the ANAF website where you will log in with the key/certificate in the system.
If the authentication was successful, you will receive the following message:
e-Factura
1. Overview
It is possible to send the invoice content with a special type of file (xml) to ANAF.
Sending invoices is mandatory, starting 1.07. 2022, for the following transactions:
B2G (business-to-government) transactions.
B2B (business-to-business) transactions containing at least one ‘high risk’ element.
B2C (business-to-consumer) transactions with holiday vouchers payment method.
Attention: As of January 1, 2024, the e-Factura system becomes mandatory for all VAT-registered companies in Romania and as of January 1, 2025, all B2C transactions must be sent to the e-Factura system.
1.1. General considerations
EBS installation version should be at least 5.8.0.1, or newer.
Each time, get and install the latest hotfixes
Some of the configurations are common with SAF-T.
1.2. New coding for counties
These can be found in the menu: Tools & Configuration > Personalization > People > Address data > Counties
It is mandatory and the Addresses column must be completed.
If SAF-T has already been set up, this step is no longer necessary as it is also included in that instruction.
This column contains the code of each county in RO and can be different from the one used for the D394 declaration.
Information can be added manually or by running an .emi
There is an .emi that we can use to update that column.
1.3. Company Person Card
A first step is to verify the information entered on the company’s person card. To avoid errors, it is advisable to make sure that the following details are mentioned:
VAT type,
Commercial Register registration number,
Address: postal code / town / (zone/sector) / county / country,
Main bank account,
E-mail address.
Attention: A service restart is required for any changes.
2. Company parameters
In the category ΑNAF Services and Declarations new parameters have been added for entering all the necessary authentication data to communicate with ANAF services for e-invoice:
BIT Services - Connection Key (Api Key). Provided by BIT Software. It is the same for SAF-T.
E-Factura - Organization Information. Click the three dots and in the pop-up window all fields must be completed. If a field is not complete, you should go back to the company person and fill in the missing information. Not in the pop-up window.
Entersoft web API - connection key. It is necessary that the client has a subscription in ES API and add the application Entersoft RO ANAF e-Factura. After that we create an endpoint key and it automatically fills in the parameter.
We first finalize the BIT services - authentication key (Api Key) and press save. It is necessary to restart the service.
Fill in E-Factura - Organization Information and press save. A restart of the service is required.
Configure the subscription in ES Cloud and create the EndPoint; *)instructions for creating a subscription in ES Cloud are detailed in the EBS-Cloud_Subscription_EN.pdf manual.
There are other parameters in the same section that manage:
real-time e-Factura transmission to ANAF This parameter will control whether the invoice will automatically go to ANAF or not. It is recommended to keep the default value = FALSE. This means that the user will press the button to send the invoice.
UDF field of the document type where the CPV code is declared (related to BT-158) This parameter requires configuration under the following conditions:
B2G transactions are involved;
The CPV code of an item is not the same in all transactions.
Customer receipt source (related to BT-158);
Buyer reference source (BT-10 related);
Item description source (related to BT-153 and BT-154).
La categoria Implementare parametri definiți, se vor utiliza:
Număr 10 (aferent BT-153 și BT-154, cazul serviciilor);
Număr 8 (aferent BT-127).
3. Document series
In the series of documents involved in the electronic invoice, select the relevant values in the following fields:
Electronic Invoice. Select the value By Vendor.
Transaction type. Select one of the values B2B or B2G, as appropriate. Only document series with the above values can be sent to ANAF.
You can use bulk modification to mass update more than one series of documents.
Warning: if the series has Direct Call Method, when we parametrize the series and the user registers a document, it will be automatically uploaded to ANAF. For any modification a re-cache is required.
4. Document types
For the document types involved in e-Factura, select the value in the SAF-T Invoice Type field, to be sent to the Invoice Type field of the file.
You can use bulk modification to mass update multiple document types.
If the values do not exist, manually open the values in the table:
Configuration and Tools > Configuration… > Documents and Series > Standard Audit File - SAF-T > Invoice Type
A re-cache is required for any changes.
5. Sectors
Another column that is mandatory and should be filled in is the Area Description column.
These can be found in Configuration and Tools > Configuration… > People > Address data > Postal codes
In that column we fill in the Sector only for ZIP Codes where the city is Bucharest.
The possible values are:
SECTOR1,
SECTOR2,
SECTOR3,
SECTOR4,
SECTOR6,
SECTOR6.
6. Customer card
For each customer for which we have a B2B or B2G transactions the following fields must be filled in:
VAT
Address: postcode, city, zone, district, country.
7. Currency
The currency code LEU should exist and the ISO code should have RON.
Warning: A service restart is required.
8. Item card
The user must fill in the following fields for items, as applicable:
Intrastat Code. For transactions categorized as B2B, the Intrastat code for all items used in the transactions must be filled in the document field of the same transaction type.
Related to e-invoicing. Any item must have this field selected.
CPV Code. For transactions that have been categorized as B2G, the document field of the same transaction type must be filled in with the CPV code, for all items used in this type of transaction.
9. CPV codes
The CPV (Common Procurement Vocabulary) code is a numerical symbol specific to a particular product or service. The CPV code establishes a single classification system for public procurement with the aim of standardizing the references used by contracting authorities and entities to describe the subject matter of public procurement contracts (B2G). The use of CPV has been mandatory in the European Union since February 1, 2006. CPV codes are used in contract award documentation and in electronic public procurement platforms, such as SEAP in Romania.
We should run an .emi to populate the table with all possible CPV codes. There is an .emi that can be used to import the list of CPV codes.
After that, the CPV codes need to be added at item level.
Below are some links we recommend for further help.
The automation that created the .xml to ANAF exports the first non-null value for the item description (chap. 16. BT-15) based on the following sequence:
Together with the client’s accountant, we should proceed with authorization by using the USB device (token) for authentication with ANAF, which each client has.
We connect to the ANAF website from the accountant’s computer using their token.
From the menu, select ANAF Authorization – Accountant and click Authorize.
The application will open your browser and ask you to select the certification under that user.
If successful, we receive the following message:
12. Transaction kind
In the document forms we have to make visible the Transaction kind field and also and in the scroller with the Sales Invoices.
13. Sent invoices - e-Factura outbound
The main screen for the management of the sent (outbound) invoices is done via the scroller accessible from the Sales > e-Factura - Management of sales invoices menu. All transaction documents to be sent to the ANAF are displayed here. The documents are grouped according to their dispatch status:
Failure - Sent but failed due to errors
Success - Delivery was successfully completed
To be sent - Not yet sent.
Pending - Has been sent but is still being processed by ANAF.
For any documents that have not been sent due to errors, the user can display the errors by clicking on the Errors field.
The following Actions are available to manage pending documents and documents that have not been sent due
to an error:
Send Invoices - Send a document that could not be sent.
Refresh status - Update the delivery status of all documents in the pending state.
Download Zip - If a document fails to send, you can download the file to disk, along with a full report of its errors. Useful when contacting support.
Download XML - If an invoice is rejected by ANAF, you can download the generated file that failed to be sent.
13.1. Retrieving the CPV code
Starting with version 5.14.0.0, the CPV code retrieval mode has been extended due to the introduction of the CPV Code field in document lines.
At the same time, in the parameters area, we have a new parameter MARK_CPV_CODE - go to menu: Configuration and Tools > Customization… > General > Company parameters > Online transaction parameters: UDF field of the document line where the item CPV code is declared.
Depending on the value of the MARK_CPV_CODE parameter, the retrieval mechanism is as follows:
If set to None, the CPV code will be taken from the document line.
If set with Comment 1 to Comment 5, it will be taken from the lines in the document (fields Comment 1 to Comment 5). However, if nothing is filled in the corresponding comment, the CPV code from the document line will be taken.
13.2. Special cases
13.2.1. Invoices with total VAT value 0
Self-invoices from suppliers who are not VAT payers,
Sales invoices exempt with/without deduction rights or non-taxable (the information in Table 5 differs).
For all of the above cases, the reason for VAT exemption is mandatory.
This may be:
If the supplier is a non-payer, the reason is VATEX-EU-O.
If it is a reverse charge sale, the reason is VATEX-EU-AE and the VAT regime on the document must be Exemption.
If it is a VAT-exempt sale (for other reasons), one of the reasons from the list can be selected, but the VAT regime must be Exemption and Table 5 must be completed correctly for VAT journal calculation.
13.2.2. Invoices with VAT category 0 lines
Although EBS does not allow the registration of an invoice with Normal VAT and lines with both 0 and non-zero VAT categories, for sales journal reasons, such cases may still arise.
In these cases, no reason for exemption shall be provided.
13.2.3. Recyclable packaging invoices
(VAT category 1 and VAT exemption regime) + special environmental tax account (excluding VAT).
13.3. Restrictions on sent invoices
Once an invoice has been successfully sent to ANAF, any changes to the invoice will produce an error. This is when the status of the invoice is Successful not the fact that it has received the Charge ID.
Verification is only done on the fields considered by EBS to be official ID data.
It is not part of this verification:
User defined fields
Business dimensions (Business Unit, Activity, Dimension1, Dimension2, Project)
Variations stock items (Lot, Serial Number, Color, Size, Dimension1, Dimension2)
Other informative fields (Alternative Argumentation, Development Step, Means of Transportation, Task etc).
In order to allow some changes for a specific group of users, it is necessary to create a document access profile by accessing the Configuration and Tools > Customize… > Documents and Series > Document access rights profile menu.
14. Received invoices - e-Factura inbound
Starting with version 5.8.0-1, the e-Factura functionality has been extended to receive SPV invoices from suppliers.
The functionalities covered are the following:
Download supplier invoices,
Download invoices list report,
Bulk saving of invoices in .pdf, .xml. and .zip format in a user selected path,
Correlate invoice downloaded from SPV with invoice already registered in EBS,
Create a new document with header data retrieval.
A new report has been added to the Purchasing & Procurement > e-Factura - inbound invoices management menu.
In addition to displaying the downloaded data, the report contains the following options:
Automation for downloading supplier invoices,
List of downloaded invoices and link (if any) to invoices already registered,
Automations to download invoices in .pdf, .zip, .xml format.
The report contains the following filter parameters:
Invoice issue number and date,
Invoice loading date,
Supplier CUI,
Supplier.
The report displays the following information;
Invoice number and date,
SPV ID and charge date,
CUI and supplier name,
Currency, values,
Upload date in EBS.
The following Actions can be executed through the available automations:
Download invoices - Download received invoices to EBS.
The automation parameters are Start date and End date for uploading invoices to SPV.
After running the automation, the report will display the invoices as selected.
Even if run multiple times over a period of time, invoices are only loaded once.
As a result of running this automation, some downloaded invoices may appear in the list with the Core check mark and an EBS document number already recorded.
The criteria by which it attempts to identify a document in the EBS are as follows:
Current company,
Trading partner with CUI similar to the one received (can be with/without RO),
Alternative document EBS = Supplier invoice number,
Alternative document date = Vendor invoice date,
Net amount = TaxExclusiveAmount or Total amount = TaxInclusiveAmount.
14.1. Download .xml
The invoice is exported in .xml format.
If the user selects a single invoice, a new screen will open with the following fields:
filename, automatically prefilled,
file path - the user will fill in the path.
If the user selects multiple invoices, the screen that will open will contain only the path that the user needs to fill in/select for the bulk saving of the invoices.
The pre-filled name of each invoice file has the following format:
Company,
Supplier name,
Invoice number,
Invoice date,
SPV ID.
14.2. Download .pdf
Export invoice in .pdf format.
The functionality is similar to the previous one (for saving .xml).
14.3. Download .zip
Export invoice in .zip format.
The functionality is similar to the previous ones (for saving .xml, .pdf).
The .zip archive contains the .xml file of the invoice and the .xml file with the signature from the SPV.
14.4. Correlations
The automation allows “matching/linking” invoices received from the SPV with invoices already registered in EBS.
In the selection screen, the supplier will be pre-filled from the line on which the cursor is positioned.
In the Documents field, select the invoice to be linked to. Only uncorrelated invoices are already displayed.
Once the automation is completed, the document number in the EBS will already be displayed in the report.
14.5. De-correlations
The automation allows you to de-match an invoice registered in EBS with one downloaded from SPV.
The purpose may be to re-match the invoice from the SPV with another document already recorded in the EBS.
14.6. Create document
If the invoice is not yet registered in EBS, the automation allows opening a new document directly from the report.
The document type will be chosen.
The following data are pre-filled:
Supplier code,
Document Date - date of upload to SPV (but can be changed),
Alternative document date - date issued by the supplier,
Invoice number - invoice number from the supplier.
The other invoice information is filled in as usual (items, quantities, prices).
Once the document has been saved, it will be automatically matched to the invoice in the SPV from which the automation was started.
14.7. e-Factura information received in other scrollers of interest
Starting with version 5.14.0.0, the functionality for downloading and correlating/decorrelating invoices received from SPV has been extended to the Purchases/Receipts scrollers (menu: Purchases & Procurement > Receipts & Purchase invoices > Purchases/Arrivals ) and Expense Documents (menu: Accounting > Expenses > Expense documents).
Three new automations are available in these:
Download e-Factura invoices
e-Factura correlation
De-correlation
The automation for Download invoices is identical in terms of functionality to that existing in the e-Factura - Management of purchase invoices scroller. More specifically, invoices received from SPV are stored in the database without, however, being correlated with invoices already registered in EBS.
The e-Factura correlation automation allows one or more selected invoices to be matched with a single invoice received from SPV. The list of invoices in SPV contains only those invoices that have not already been correlated with an invoice in EBS.
The De-correlation automation “unlinks” the SPV invoice from the invoice(s) in EBS.
These scrollers have also been expanded by adding three new columns:
e-Factura document: supplier’s invoice number;
RequestID: e-Factura ID downloaded from SPV;
Correlated: indicates whether the invoice in EBS is correlated with a document in SPV.
These columns are initially hidden, but can be displayed in the scroller by right-clicking on the column header and selecting the Add/Remove Columns command.
The three columns are updated through the specific e-Factura automations mentioned above.
15. Source fields eFactura
To view how to fill in the form manually in SPV, please use the link below:
The unique document number from EBS (ADCode) is transmitted.
BT-2 Invoice issue date
The date of registration of the document (ADRegistrationDate) is transmitted.
The section in xml where the field appears is: /Invoice/cbc:Issued.
BT-3 Invoice type code
The SAFT document type is transmitted from the series or, if there is no value, from the Document type.
Possible values:
380 – Standard invoice
381* – Credit note
384 – Correction invoice
389 – Self-invoicing
The section in xml where the field appears is: /Invoice/cbc:InvoiceTypeCode.
The invoice type affects the overall sign of the document.
With the exception of type 381, all invoice types are interpreted by ANAF exactly as transmitted, regardless of the sign.
The sign transmitted in xml can be:
380 – plus or minus;
381 - more;
three hundred and eighty-four – less;
389 – plus or minus.
From the EBS application perspective, the document sign, as a functionality for the VAT declaration, comes from the Transaction category*, set at the document type level.
*) There are exceptional cases where this field is not filled in even though the invoice is sent to SPV.
The transaction category can be:
01 – Invoice with surplus;
02 - Debit note;
03 – Credit note (negative invoice).
Therefore, in order to avoid changing the current settings, this field will be sent as follows:
If it is 380 and the transaction category is 01/02 or not filled in: code 380 and positive sign;
If it is 380 and the transaction category is 03 - code 380 and negative sign;
If it is 381 - code 381 and positive sign;
If it is 384 - code 384 and negative sign;
If it is 389 and the transaction category is 01/02 - code 389 and positive sign;
If it is 389 and the transaction category is 03 - code 389 and negative sign.
BT-5 Invoice currency code
The ISO code of the currency of the document is transmitted. This affects whether or not the BT-111 field is transmitted. If RON is specified here, the BT-111 field is not transmitted in the e-Invoice.
The section in xml where the field appears is: /Invoice/cbc:DocumentCurrencyCode
BT-6 Invoice currency code of VAT
Transmit RON.
The section in xml where the field appears is: /Invoice/cbc:TaxCurrencyCode.
BT-7 Invoice VAT date effective
The first non-zero value between the Delivery Date and the Document Date is transmitted;
The section in xml where the field appears is /Invoice/cbc:TaxPointDate.
BT-9 Payment due date
Either the first due date (in the Payment Order tab or Trade Bills tab) or the document date (if the remaining total to be paid is 0) is sent.
The section in xml where the field appears is: /Invoice/cbc:Due or /CreditNote/cac:PaymentMeans/cbc:PaymentDueDate.
Starting with version 5.13.0.0, a new parameter in the ANAF services and declarations section, E_FACTURA_DueDate_Source, will allow the selection of the date used for this field.
Possible values are:
0 – current method (i.e., either the earliest due date* in the Payment Order/Commercial Paper tab) or the document date (if the payment amount of the document is 0);
1 – the earliest estimated date** in the Payment disposition or document date table (if the total amount is 0).
*) Due date = Valeur Date.
**) Estimated date = Collection Date.
BT-10 Buyer Reference
This field must contain the supplier code for the customer to whom the invoice is issued.
Since there is no dedicated field for this information, the field will be filled in either in one of the UDF fields on the customer card or in the invoice header.
To determine the field from which the information will be retrieved, set the new parameter in the ANAF services and declarations area E_FACTURA_SourceBuyerReference.
Possible values range from 1 to 19 with the following meanings:
Values from 1 to 10 correspond to the Comment 1 to 10 field on the customer card;
Values from 11 to 15 correspond to Comment fields 1 to 5 in the document header;
Values from 16 to 19 correspond to fields Table 1 to Table 4 in the document header.
The section in xml where the field appears is: /Invoice/cbc:BuyerReference.
BT-11 Project Reference
The source is the alternate code of the project selected on the document.
The section in xml where the field appears is: /Invoice/cac:ProjectReference/cbc:ID.
BT-12 Contract reference
The source is the alternative code of the contract selected on the document.
The section in xml where the field appears is: /Invoice/cac:ContractDocumentReference/cbc:ID.
BT-13 Purchase order reference
The source is an alternative document from the invoice header or one of the user-defined fields (Comment 1 to 5), depending on the value of the parameter E_FACTURA_SourcePurchaseOrderReference_BT13:
0 – Alternative document;
1 – Comment 1;
2 – Comment 2;
2 – Comment 3;
3 – Comment 4;
4 – Comment 5.
The section in xml where the field appears is: /Invoice/cac:OrderReference/cbc:ID.
BT-14 Sales order reference
The source is the Reference Document field (ConcerningDocCode*) in the Information tab. It must always be the COV number or the first document registered as an order in EBS.
Considering that existing transitions do not inherit this field by default, the implementation proposal is:
The first transition from a command (COV/CVR) copies the ADCode field from the source to DocConcerningCode in the destination.
All other transitions should take DocConcerningCode from source to destination.
This is also useful in other cases, especially when reports on orders are requested and the flow is very long. Having a field across the entire flow that indicates the initial order is extremely useful.
The section in xml where the field appears is: /Invoice/cac:OrderReference/cbc:SalesOrderID.
BT-15 Receipt reference
This field must contain the receipt number provided by the customer to whom the invoice was issued.
Since there is no dedicated field for this information, one of the UDF fields in the document header will be used.
To determine the field from which the data will be retrieved, set the parameter E_FACTURA_SourceReceiptReference to a value between 1 and 5.
Each value corresponds to a Comment from 1 to 5 in the header.
The section in xml where the field appears is: /Invoice/cac:ReceiptDocumentReference/cbc:ID.
BT-16 Despatch Note Reference
The field Relative document is taken over.
The section in xml where the field appears is: /Invoice/cac:DespatchDocumentReference/cbc:ID.
BT-20 Payment terms
The description of the payment method in the document is transmitted.
The section in the XML where the field appears is: /Invoice/cac:PaymentTerms/cbc:Note.
BT-22 Invoice note
The Comment, argumentation, or alternative argumentation field from the document header is transmitted, depending on the value of the E_FACTURA_SourceInvoiceNote_BT22 parameter:
0 - Comment;
1 - Argumentation;
2 – Alternative argument.
The section in xml where the field appears is: /Invoice/cbc:Note.
BT-27 Seller’ name
Transmitted:
Name of the company representative if it is a sales document;
Name of the supplier if it is an invoice issued by the taxable person as the beneficiary (self-invoice).
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName.
BT-28 Seller’ trade name
Transmitted:
Name of the company representative if it is a sales document
Name of the supplier if it is an invoice issued by the taxable person as the beneficiary (self-invoice).
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name
sau /CreditNote/cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name.
BT-29 Seller identifier
The seller’s GLN is taken from the main company address or the main supplier address, if it is a self-invoice.
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID.
BT-30 Seller legal registration
The seller’s Trade Reg. No. (own company or supplier) is taken over.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID.
BT-31 Seller VAT identifier
The company’s own CUI or the supplier’s CUI is used if it is a self-invoice issued by the taxable person as the beneficiary.
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID.
Note: The field is not transmitted at all if the reason for exemption is VATEX-EU-O (according to ANAF specifications).
BT-33 Additional legal information about the Seller
The company type field (SA, SRL, etc.) is taken from your own company or supplier.
The seller’s address 1 is taken from the main company address or the main supplier address, if it is a self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:StreetName.
BT-36 Seller additional address
The seller’s address 2 is taken from the main company address or the main supplier address, if it is a self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:AdditionalStreetName.
BT-37 Seller city
The seller’s city is taken from the company’s main address or the supplier’s main address, if it is a self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CITYNAME.
BT-38 Seller postal code
The seller’s postal code is taken from the company’s main address or the supplier’s main address, if it is a self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:PostalZone
sau /CreditNote/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:PostalZone.
BT-39 Seller country subentity (judet)
The abbreviation of the seller’s county is taken from the main company address or the main supplier address, if it is a self-invoice.
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CountrySubentity.
BT-40 Seller country
The ISO code for the seller’s country is taken from the main company address or the main supplier address, if it is a self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode.
BT-42 Seller contact phone
The phone number is taken from the company’s main address.
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone.
BT-43 Seller contact email
The email address set at the interlocutor level in the document header is retrieved.
The section in xml where the field appears is: /Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone.
BT-44 Buyer’s name
The name of the buyer (your own company, if it is a supplier self-invoice, or the customer in the document) is taken.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName.
BT-45 Buyer’s trade name
The name of the buyer (your own company, if it is a supplier self-invoice, or the customer in the document) is taken.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyName/cbc:Name.
BT-46 Buyer identifier
The GLN of the buyer’s main address is taken (business partner document or company, if it is a supplier self-invoice).
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID.
BT-47 Identifier for a legally registered Buyer
The buyer’s Trade Reg. No. is taken (business partner document or company, if it is a supplier self-invoice).
For individuals, if the CNP is filled in on the person’s card, it will be transmitted. Otherwise, the fixed value 0000000000000 will be transmitted.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID.
BT-48 Buyer’s tax identifier
The buyer’s CUI (business partner document or company, if it is a supplier self-invoice) is taken over.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID.
BT-50 Buyer address line 1
The Address 1 field is taken from the main address of the customer or company, if it is a supplier self-invoice.
The section in the XML where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:StreetName.
BT-52 Buyer city
The city is taken from the customer’s or company’s main address - for supplier invoices (for Bucharest, the description of the area from the postal code of the main address).
The section in the XML where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:CITYNAME.
If the postal code is not filled in on the customer’s card, for customers in Bucharest, it will be filled in as SECTOR1, SECTOR2, etc.
BT-53 Buyer postal code
The Postal Code field is taken from the main address of the customer or company, if it is a supplier self-invoice.
This field is not mandatory.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:PostalZone.
BT-54 Buyer county
The abbreviation of the county corresponding to the main address of the customer or your own company is taken (for supplier self-invoices).
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:CountrySubentity.
BT-55 Buyer country
The ISO code of the country corresponding to the main address of the customer or your own company is taken.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode.
BT-57 Buyer’s contact phone
The phone number is taken from the business partner’s address in the document.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:Contact/cbc:Telephone.
BT-58 Buyer’s contact email address
The email address is taken from the Interlocutor field in the document header.
The section in xml where the field appears is: /Invoice/cac:AccountingCustomerParty/cac:Party/cac:Contact/cbc:ElectronicMail.
BT-70 Shipping on Behalf of a Party
The name of the recipient is taken (it may be different from the customer itself).
sau /CreditNote/cac:Delivery/cac:DeliveryParty/cac:PartyName/cbc:Name.
BT-71 Delivery location Identifier
The GLN delivery address is taken over.
The section in xml where the field appears is: /Invoice/cac:Delivery/cac:DeliveryLocation/cbc:ID.
BT-72 Actual delivery date
The delivery date is taken from the document or the date of issue (if the delivery date is NULL).
The section in xml where the field appears is: /Invoice/cac:Delivery/cbc:ActualDeliveryDate.
BT-75 Delivery address, line1
The Address 1 field corresponding to the delivery address in the document is retrieved.
The section in the XML where the field appears is: /Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:StreetName.
BT-77 Delivery City
The city corresponding to the delivery address in the document (if not Bucharest) or the area description from the postal code corresponding to the delivery address is taken.
The section in the XML where the field appears is: /Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:CITYNAME.
BT-78 Delivery postal code
The postal code corresponding to the delivery address is taken.
The section in the XML where the field appears is: /Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PostalZone.
BT-79 Delivery county
The Abbreviation field is taken from the county corresponding to the delivery address.
Secțiunea din xml la care câmpul apare este: /Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:CountrySubentity.
BT-80 Delivery country
The ISO code is taken from the country corresponding to the delivery address.
The section in the XML where the field appears is: /Invoice/cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode.
BT-81 Payment means code
The section in xml where the field appears is: /Invoice/cac:PaymentMeans/cbc:PaymentMeansCode.
The values that can be sent are as follows:
10 - Flat rule = Cash or Cash Advance or Cash on Due Date;
42 - Flat rule = On Credit;
20 - Flat rule = Check/BO =>;
49 - Flat rule = Direct Debit or Direct Deposit;
48 - Flat rate = Credit card;
ZZZ - Flat rule = Gift vouchers;
97 - Flat rule = Compensation;
One of the following values is transmitted from the EBS:
48 - there is data in the Payment Order/Credit Card tab;
20 - there is data in Payment Order/Commercial Paper;
10 - there is data in the Payment Order/Cash tab;
42 - there is data in Payment Order/on Credit and the cash account has an associated bank;
10 - for any other case. (Gift cards, for example).
For mixed payments, the order in which the information is verified to determine which payment is sent first is:
Lines: Payment Order/Cash Tab; Payment Order/Cash Tab; Payment Order/Credit Tab. If all three are filled out, the line number matters — that is, the order in which they were entered. The forecast line (Credit) is usually the last one.
Payment Orders/Commercial Paper
Gift card lines.
BT-84 Payment Account Identifier
Either the IBAN field corresponding to the seller’s main account (own company or supplier, in the case of self-billed invoices) or a list of IBAN accounts is transmitted.
The configuration is done through the parameter E_FACTURA_BankAccount_Source, where the values mean:
0 (Default): only the IBAN for the main account;
1: IBANs for accounts that have Feature 1 checked;
2: IBANs for accounts that have checked Feature 2.
3: IBANs for accounts that have checked Feature 3.
The section in xml where the field appears is: /Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID.
BT-85 Payment Account Name
The name of the bank associated with the seller’s main account (own company or supplier, in the case of self-billed invoices) is provided.
The section in xml where the field appears is: /Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:Name
Depending on the parameter set for BT-84, multiple banks associated with IBANs from BT-84 can also be transmitted in BT-85.
BT-106 Total of all Net Amounts for Invoice Items
The net value in foreign currency is taken from the item lines and special account lines.
The sign is calculated correctly according to the row type. Only independent special accounts are transmitted.
The section in xml where the field appears is: /Invoice/cac:LegalMonetaryTotal/cbc:LineExtensionAmount
sau /CreditNote/cac:LegalMonetaryTotal/cbc:LineExtensionAmount.
BT-107 Total of Document- level Discounts
0 is transmitted because the values are already included in the lines.
The section in xml where the field appears is: /Invoice/cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount
sau /CreditNote/cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount.
BT-108 Total of Document- level Charges
0 is transmitted because the values are already included in the lines.
The section in the XML where the field appears is: /Invoice/cac:LegalMonetaryTotal/cbc:ChargeTotalAmount
sau /CreditNote/cac:LegalMonetaryTotal/cbc:ChargeTotalAmount.
BT-109 Total Invoice Amount Without VAT
The net value in foreign currency is taken from the item lines and special account lines.
The section in xml where the field appears is: /Invoice/cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount
sau /CreditNote/cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount.
BT-111 Total Amount of VAT in the Accounting Currency
The VAT amount is transmitted both from the item lines and from the special accounts (if any).
This field is transmitted only if the transaction currency is different from RON (BT-5).
The section in xml where the field appears is:
/Invoice/cac:TaxTotal/cbc:TAXAMOUNT
sau /CreditNote/cac:TaxTotal/cbc:TAXAMOUNT.
BT-112 Total Amount of Invoice with VAT
The total value in currency from the item lines + special account lines is transmitted.
sau /CreditNote/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:Percent.
BT-120 Reason for VAT Exemption
Starting with version 5.13.0.0, this information will also be transmitted in eFactura.
The source of this field will be configured based on the values set in the E_FACTURA_TaxExemptionReason_Source parameter in the ANAF Services and Declarations area.
Possible values:
0 – Alternative description of the reason for VAT exemption (from ESFIZVatExemptionReasoning). For example: Reverse charge – for VATEX-EU-AE or Not subject to VAT – for VATEX-EU-O;
1 – Comment 1;
2 – Comment 2;
3 – Comment 3;
4 – Comment 4;
5 – Comment 5;
6 – Argumentation;
7 – Alternative argumentation;
8 – Alternative description in Table 5 (ESFIZDocumentHeadersTable5). For example: Exempt - Reverse charge under the conditions of Article 331 (for VATEX-EU-AE).
BT-121 Code for the Reason for VAT Exemption
The reason for VAT exemption is transmitted in the document header.
sau /CreditNote/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode.
BT-122 Reference to Supporting document
Depending on the value of the E_FACTURA_ReferenceSupportingDocument_BT122 parameter, the information can be retrieved:
0 – NULL;
1 – Comment 1 from invoice header;
2 – Comment 2 from invoice header;
3 – Comment 3 from invoice header;
4 – Comment 4 from invoice header;
5 – Comment 5 from invoice header;
6 – Amount 1 from the invoice header;
7 – Amount 2 from the invoice header;
8 – Amount 3 from the invoice header;
9 – Amount 4 from the invoice header;
10 – Amount 5 from the invoice header.
BT-123 Description of Supporting document
Depending on the value of the E_FACTURA_DescriptionSupportingDocument_BT123 parameter, the information can be retrieved:
0 – NULL;
1 – Comment 1 from invoice header;
2 – Comment 2 from invoice header;
3 – Comment 3 from invoice header;
4 – Comment 4 from invoice header;
5 – Comment 5 from invoice header;
6 – Amount 1 from the invoice header;
7 – Amount 2 from the invoice header;
8 – Amount 3 from the invoice header;
9 – Amount 4 from the invoice header;
10 – Amount 5 from the invoice header.
BT-126 Invoice Item Identifier
The line number is transmitted if it concerns articles.
The lines of the special accounts are numbered consecutively.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cbc:ID.
BT-127 Item Notes
If it is NOT a stock item, send a fixed value Line Item.
If it concerns stock items, depending on the parameter E_FACTURA_SourceItemNotes_BT127, the following can be sent:
0 – Fixed value Line Item;
1 – Comment 3 Document series + Number 1 line article;
2 – Comment 3 Document series + Number 1 line article;
3 – Comment 3 Document series + Number 1 line article;
4 – Comment 3 Document series + Number 1 line article;
5 – Comment 3 Document series + Number 1 line article;
11 – Comment 1 in the article line;
12 – Comment 2 in the article line;
13 – Comment 3 in the article line;
14 – Comment 4 in the article line;
15 – Comment 5 in the article line.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cbc:Note.
BT- 129 Invoiced Quantity
The amount in the document lines or fixed value 1 (for special accounts) is transmitted.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cbc:InvoicedQuantity.
BT-130 Code for Unit of Measurement for Invoiced Quantities
The code SAFT of the UM in the document lines or a fixed value (H87) for special accounts is transmitted.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cbc:InvoicedQuantity/@unitcode.
BT-146 Net Item Price
The result of dividing the net value in foreign currency by the quantity is reported, if the quantity is not zero.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Price/cbc:PriceAmount.
BT-149 Item Unit Price
Starting with version 6.0.0-0, the value 1 is transmitted. This column reflects the quantity to which the unit price applies. In EBS, it can only be 1.
The section in the XML where the field appears is: /Invoice/cac:InvoiceLine/cac:Price/cbc:BaseQuantity.
BT-150 Code for Measuring a Quantity of Items as a Unit
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Price/cbc:BaseQuantity/@unitcode.
BT-151 VAT Category Code for Invoiced Items
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID
If the line has a VAT value, S is transmitted.
If the line has a VAT value of 0, then:
If there is no reason filled in the header: Z;
If the reason VATEX-EU-O exists: O
If there is a VATEX-EU-AE reason: E (this cannot be filled in if the line has VAT category 0, but only if the VAT regime of the document is Exemption);
If there is another reason (apart from VATEX-EU-AE): E.
BT-152 VAT Rate for Invoiced Items
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:Percent
The field is not transmitted at all if the reason for exemption is VATEX-EU-O.
0 can be transmitted even if the VAT category in the line is <> 0 (if Document VAT regime = Exemption).
Grouping is done at the level of the VAT percentage transmitted (VATPercentage field), which comes from the VAT line value and not from the VAT line category.
BT-153 Item description
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cbc:Name,
Described in BT-154.
BT-154 Product name
Both fields take the first non-null information in the following order:
The Description field in Multiple Item Codes for Comment 1 = customer code;
Comment field 1 of related persons on the article/client;
Another source:
If it concerns stock items: send the description according to the parameter E_FACTURA_ITEM_DES (from the ANAF area) as follows:
From 1 to 5 – Comment 1 to 5 in the document line;
6 – Inline comment;
7 – In-line argumentation.
If generic items are involved, the description is sent according to the parameter Number 10 (from the Implementation – definition parameters area). The values can be: From 1 to 5 – Comment 1 to 5 in the document line;
If the parameter is set to a field other than the item description and that field is not filled in, the item description will be sent.
The section in xml where the field appears is: Invoice/cac:InvoiceLine/cac:Item/cbc:Description.
BT-155 Item identifier of seller
The item code is sent.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:SellersItemIdentification/cbc:ID.
BT-156 Item identifier of buyer
The first non-zero value is sent in the following order:
Multiple codes: Comment 1 = partner code;
Multiple codes: Comment 1 = partner name;
Related persons: Code;
Item code.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:BuyersItemIdentification/cbc:ID.
BT-157 Standard Item identification
Depending on the parameter E_FACTURA_SourceStandardItemIdentifier_BT157, the source can be:
Value 0: the first non-zero value is taken in the following order:
Code field in Multiple codes: UM = UM document line and comment 1 NULL;
Item barcode;
Code field in Multiple codes: Comment 1 = Partner code;
Code field in Multiple Codes: Comment 1 = Partner name.
Value 1: the first non-zero value is taken in the following order:
Item barcode;
Code field in Multiple codes: UM = UM document line and comment 1 NULL;
Code field in Multiple codes: Comment 1 = partner code;
Code field in Multiple codes: Comment 1 = partner name.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID.
BT-158 Item Classification Identifier
The Intrastat code or the CPV code shall be transmitted.
The CPV code can be taken from different sources depending on the value of the MARK_CPV_CODE parameter (in the Electronic Transaction Parameters area):
If set to None: the CPV code will be taken from the item card;
If set to Comment 1 to Comment 5: will be taken from the lines in the document.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode.
BT-159 Country of Origin of Item
The ISO code of the country of origin set on the item card is transmitted. If it does not exist, nothing is transmitted. The field is optional.
The section in xml where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:OriginCountry/cbc:IdentificationCode.
BT-160 Item Attribute Name
This field can transmit an attribute type such as color, size, batch, SN.
Currently sending NULL.
The section in XML where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:AdditionalItemProperty/cbc:Name.
BT-161 Item Attribute Value
This field can transmit the value of an attribute such as color, size, batch, SN.
Currently sending NULL
The section in XML where the field appears is: /Invoice/cac:InvoiceLine/cac:Item/cac:AdditionalItemProperty/cbc:Value
The legislative basis for this implementation is OUG 41/2022, amended by OUG 115/2023. The Ministry of Public Finance, through ANAF, has made available a guide that can be found here.
Implementing e-Transport requires the following steps:
Upgrade to the latest version of EBS (at least 5.8.0-1).
SaaS agreement based on the number of operations (documents).
Implementation—this involves both activities performed by consultants (e.g., creating new document types) and the client filling in their own nomenclatures and mandatory data in documents.
Training - this is optional if the current procedure covers the flows.
support.
2. General aspects
According to the legislative basis, ANAF will monitor in real time the movement of goods with high fiscal risk on Romanian territory, the transport of goods purchased and delivered within the EU, the transport of goods subject to customs operations, and the transport of goods between two locations on national territory.
The types of operations involving road transport of goods are:
purchases of goods,
sales of goods and
transfers of goods.
The necessary data to be defined in EBS may include:
New nomenclatures: Customs offices, border crossing points, and operation purpose. Starting with version 5.8.0-2 EBS-RO, these nomenclatures, together with the related migration scenarios, can be found in the application folder ESMigration.
Own nomenclatures (carriers, means of transport, etc.).
3. Nomenclature management
3.1. Customs offices
The list of customs offices can be found in the menu Configuration and Tools > Customization… > Transaction parameters > Customs.****
3.2. Border crossing points
The list of border crossing points can be found in Configuration and Tools > Customization… > Transaction Parameters > Border crossing points.
3.3. Purpose of the operation
The list of operation purposes can be found in Configuration and Tools > Customization… > Transaction parameters > Shipping purposes.
3.4. Type of operation
Currently, the type of operation is represented by the first two characters of the Operation Purpose.
There is no separate nomenclature.
However, considering that four new types of operations have been introduced, a separate nomenclature for operation types will be available in a later version.
Code
Meaning
Changes from the previous version
10
Intra-Community acquisition
12
Contract manufacturing (EU) - entry
new entry
14
Call-off stock - entry
new entry
20
Intra-Community supply
22
Contract manufacturing (EU) - output
new entry
24
Call-off stock - outbound
new entry
30
Transportation within the country
40
Import
50
Export
60
Intra-Community transaction - Entry for storage/formation of new transport
70
Intra-Community transaction - Removal after storage/formation of new transport
3.5. Transporters
These can be updated by accessing the Configuration and Tools > Customization… > Transaction parameters > Transporters or via Main menu >Sales > Trade Accounts > Carriers menu. Click on the green “+” icon in the upper right corner to add.
All details must be filled in: tax registration number, address, city, county, country.
3.6. Means of conveyance
These are updated in the Configuration and Tools > Customization… > Transaction parameters > Means of conveyance menu.
In the Code column, enter the registration number (without spaces, lines, or dots—e.g., B111CMD).
3.7. Trailers
These are updated in the Configuration and Tools > Customization… > Transaction parameters > Means of conveyance menu.
In the Code column, enter the registration number (without spaces, lines, or dots—e.g., B111CMD).
3.8. Routes
These are updated in the menu Configuration and Tools > Customization… > Transaction parameters >Routes.
The purpose of the route is to create the necessary combinations between the border crossing point (RO: customs crossing point) and/or customs office (RO: customs offices).
The code is not important, but it should be suggestive for your own use, as you will need to select the itinerary on each document. What is important is to select the values for the Border crossing code and/or Customs code column for each itinerary.
Attention: Depending on the type of operation, there are certain restrictions on filling in this information.
For example, the customs office is only filled in for imports and exports, but only if the customs formalities take place on national territory, at a customs office. If the customs formalities take place outside the national territory, the border crossing point will be filled in.
Type
Code
Stage
Selectable location
Description of type of place/case
10
AIC
Start
codPtf
PTF (The road route begins at a border crossing point - entry direction)
10
AIC
Final
codPtf
PTF (The road route ends at a border crossing point - exit direction)
12
LHI
Start
codPtf
PTF (The road route begins at a border crossing point - entry direction)
14
SCI
Start
codPtf
PTF (The road route begins at a border crossing point - entry direction)
20
LIC
Final
codPtf
PTF (The road route ends at a border crossing point - exit direction)
22
LHE
Final
codPtf
PTF (The road route ends at a border crossing point - exit direction)
24
SCE
Final
codPtf
PTF (The road route ends at a border crossing point - exit direction)
40
IMP
Start
codPtf
PTF (Customs formalities take place outside the national territory)
40
IMP
Start
codBirouVamal
BV (Customs formalities take place on national territory, at an import customs office)
50
EXP
Final
codPtf
PTF (Customs formalities take place outside the national territory)
50
EXP
Final
codBirouVamal
BV (Customs formalities take place on national territory, at an export customs office)
60
DIN
Start
codPtf
PTF (The road route begins at a border crossing point - entry direction)
70
DIE
Final
codPtf
PTF (The road route ends at a border crossing point - exit direction)
\
4. Company parameter settings
Go to the menu Configuration and Tools > Customization… > General > Company parameters
to set the following parameters:
Implementation (User definable parameters) > User defined parameter - Number 9 (UDEFNUM09)
The impact is the source of the gross weight for each item.
It can be set to values from 0 to 15.
0: Net weight - the weight in the Weight field in the document line.
from 1 to 10: Quantity in UMB from the document line * Numbers 1-10 on the item card.
from 11 to 15: Amount 1-5 in the document line.
The default value is 0 - the weight field in the document line.
Regardless of the source, the gross weight will be rounded to 2 decimal places.
ANAF services and declarations > e-Transport - Item UDF field where the item code is entered (E_TRANSPORT_ITEM_CODE)
This parameter defines the source for retrieving the item code.
Possible values:
1: Code
2: Alternative code
3: Tax code
4: International code
5: Net profit factor code
6: Intrastat code
7: Customs tariff class
8: From 8 to 17: Comment 1 to 10 from the item card.
The default value is 3 - tax identification code. The recommended value is 6.
5. Connection with ANAF
Go to the Configuration and Tools > System integrations > Connection settings > ANAF - Accountant authorization menu and click the Authorization for e-Transport button.
6. Documents
For each shipment, a document must be created containing several details in order to submit a complete request to ANAF and obtain the shipment code - UIT.
Two new types of documents will be used, ETR_S and ETR_P, related to delivery and purchase operations, respectively. The two types of documents have no impact on the system other than being the source for obtaining the UIT code. Their functionality is as follows:
allow obtaining a UIT code for multiple orders
allow management of the date of obtaining the UIT code: other than that of the initial order.
The two types of documents are generated by the newly created transitions from the source documents.
Possible flows at Acquisition:
CCOC-NIR-FRC
COC-PRC-NIR-FRC
COC-PRC-RO.FRC-RO.NIR, etc.
Since the UIT code must be obtained when the goods are loaded, it is very important that the ETR_* document be generated from the source document(s). More specifically, either from the COC if working on the first flow above, or from the PRC if working on the second flow.
Below are the fields that must be completed on the document for e-Transport purposes in the “Other data” tab:
Transporter
Route
Means of transportation
Trailer no. 1 - optional
Trailer no. 2 - optional
Purpose of shipment
Doc. type (e-Transport) - here you can set a default value with the possibility of modification.
It is also important to have the measurement units for weight on all items.
7. Special fields
Loading area
This field is only transmitted when road transport begins on national territory.
The source is the warehouse field, which must contain information about the city, county, country, and postal code. The most common cases are related to deliveries:
Type
Code
Stage
Selectable location
Description of type of place/case
Source: EBS
20
LIC
Start
location
ADR (The road route begins on national territory)
Warehouse
30
TTN
Start
location
ADR (The road route begins on national territory)
Warehouse
50
EXP
Start
location
ADR (The road route begins on national territory)
Warehouse
70
DIE
Start
location
ADR (The road route begins on national territory)
Warehouse
In the case of intra-community acquisitions or imports, this field may be transmitted if the road transport starts on national territory but at a border crossing point (AIC case) or customs office (IMP). Note: This case is not currently covered; it is under review to identify the appropriate data source.
Type
Code
Stage
Selectable location
Description of type of place/case
10
AIC
Start
location
ADR (The road route begins at a place on national territory other than a BCP - border crossing point)
40
IMP
Start
location
ADR (Customs formalities take place on national territory, at a location other than a customs office)
60
DIN
Start
location
ADR (The road route begins at a place on national territory other than a BCP)
Unloading location
This field is only transmitted if the place of unloading is on national territory.
Type
Code
Stage
Selectable location
Description of type of place/case
Source: EBS
10
AIC
Final
location
ADR (The route ends within the national territory)
Warehouse/Shipping address
30
TTN
Final
location
ADR (The route ends within the national territory)
Warehouse/Shipping address
40
IMP
Final
location
ADR (The route ends within the national territory)
Warehouse/Shipping address
The most common cases are related to purchases. Considering that, in the case of purchases, the destination within the country can be a warehouse or a customer address in Romania, the source of this field can be Warehouse or Shipping address. To align the working method, the Shipping address will be used to assign the final location.
Considering that, as standard in EBS-RO, this field is always filled in with the business partner’s details, and that, in the case of purchases, it must be either a customer’s address in RO or your own address in RO, an FPP will be installed that will automatically fill in:
Recipient: own company
Address: warehouse
Both fields can be modified with a client address.
In the case of deliveries, this field may be transmitted if the route ends on national territory but not at a border crossing point or customs office.
Please note: This case is not currently covered; it is under review.
Type
Code
Stage
Selectable location
Description of type of place/case
20
LIC
Final
location
ADR (The road route ends at a location within the national territory other than a BCP)
50
EXP
Final
location
ADR (Customs formalities take place on national territory, at a location other than a customs office)
60
DIN
Final
location
ADR (The route ends within the national territory)
70
DIE
Final
location
ADR (The road route ends at a location within the national territory other than a BCP)
Trading partner
The data transmitted for the trading partner is:
TRN
Country (ISO code)
Name
The data source is the field Agent (which is in most cases identical to the trading partner). However, there are cases where the two fields are not identical.
For example, an import purchase where customs formalities are carried out at a customs office in Romania. However, the invoice is issued by a supplier in the EU.
The purpose of the operation for eTransport will be related to import, and in the field Agent the trading partner from where the goods are sent will be filled in.
Transport document number
There is an e-Transport parameter found in Configuration and Tools > Customization… General > Company parameters menu in the ANAF services and declarations group: Source of document number (E_TRANSPORT_SOURCE_DOC_NO).
It can accept various values depending on which the Document No. field will be taken.
Current document number
Comment 1 to 5
Argumentation
Alternative argumentation
Comment
AWB number (if EBS integration was used)
\
8. e-Transport scroller
To request the transport code from ANAF, access the menu: Inventory > e-Transport - Shipment management.
The related automations are:
8.1. Create UIT
The Create UIT button sends all data associated with the selected document to ANAF, and if everything is OK, you will receive the ID for the associated transport - UIT code.
8.2. UIT Confirmation
There is also an option to receive confirmation of the UIT code. This is possible through the UIT Confirmation automation launched by the button of the same name.
8.3. Modify UIT
The next button, Modify UIT, launches an automation that allows resending a modified document that already had a valid UIT code.
8.4. Update UIT status
The Update UIT status button calls the automation to update the information in the Update status column for the selected documents (lines).
8.5. Download UIT
The Download UIT button should be used to download the UIT file in xml format.
8.6. Delete UIT
The option to delete an obtained UIT code has also been added. This is possible through the automation called by the last button - Delete UIT.
9. e-Transport v2
In order to introduce new functionalities, ANAF has developed a new version of e-Transport. This still works in parallel with the first version. To simplify things, SBS e-Transport, which is the basis for ensuring the integration of e-Transport into EBS-RO, can differentiate, depending on the parameters in which the request is formulated, which of the versions will be used to continue communication with ANAF. Therefore, only minimal parameterization is required for the EBS-RO user.
Important: Only e-Transport v2 covers intermodal transport.
9.1. Preliminary considerations
In order for EBS-RO to use these new features, the following are required in advance:
The latest Hotfix for EBS-RO version 5.13.0-3 must be installed.
Configure the shipping goals.
Configure itineraries (only for intermodal transport).
9.2. Purpose of shipment
Go to the settings page: Configuration and Tools> Customization… > Transaction Parameters > Shipping Purposes.
Two pieces of information are extracted from the Shipping value field for UIT:
Type of operation and
Scope of the operation - purpose of the shipment.
The scope of the operation will indicate whether the UIT structure is v1 or v2.
The purpose of shipping in v1
The shipping purpose will contain:
Shipping purpose: all digits.
Operation type: first 2 digits.
The purpose of shipping in v2
The value of the goal contains:
Shipping purpose: first digits before #.
Operation type: the 2 digits after #.
List of examples of types of operations in v2 (same as in v1):
Code
Description
Descriere RO
10
Purchase from EU
Achiziţie intracomunitară
20
Sales to EU
Livrare intracomunitară
30
Transport within RO
Transport pe teritoriul naţional
40
Purchase non EU
Import
50
Sales non EU
Export
List of examples for shipping purpose in v2 - (these are different from v1):
Code
Description
Descriere RO
101
Commercial
Comercializare
201
Production
Producție
301
Grants
Gratuități
601
Own use
Consum propriu
704
Transfer between warehouses
Transfer între gestiuni
801
Leasing
Leasing financiar/operațional
9901
Other
Altele
9.3. Routes
For intermodal transport, routes must contain:
Address
City
District
Country
Postal code
No customs codes or border crossing points will be established for this type of route.
The route will be used in documents in the same way as it is currently used.
To define a route, go to the settings page: Configuration and Tools > Customization… > Transaction Settings > Routes.
\
10. Legal basis details
The Ministry of Public Finance has a section entirely dedicated to e-Transport legislation, which can be consulted here.
Applicability of ordinances:
Reporting obligations - from December 15, 2023
Penalties - from July 1, 2024
Legislative summary:
Government Emergency Ordinance 115/2023 amends and supplements Government Emergency Ordinance 41/2022 establishing the national system for monitoring road transport of goods with high fiscal risk, RO e-Transport, as follows:
The RO e-Transport System monitors domestic road transport of goods with high fiscal risk and international road transport of goods.
Declaration of shipments of goods with high fiscal risk on national territory, based on the UIT code, taking into account the limitations provided - goods with high fiscal risk with a total gross weight exceeding 500 kg or a total value exceeding 10,000 lei)
Declaration of international road transport of goods, based on the UIT code (note that this does not specify only high fiscal risk, but generalized risk, all goods subject to international transport, without specifying limitations on total mass or total value)
Excerpt from GEO 115, Art. 1, para. 2: The RO e-Transport System monitors domestic road transport of goods with high fiscal risk and international road transport of goods.
*Who declares data relating to international freight transport in the RO e-Transport system?*
The obligation to declare in the RO e-Transport System the data provided for in Article 4(1)(a) relating to international transport of goods (intra-Community acquisitions and deliveries, imports, and exports) lies with the following users: (a) persons who, in their capacity as economic operators, carry out international transport of goods; (b) persons who, in their capacity as economic operators, carry out intra-Community acquisitions and deliveries, imports, and exports; (c) persons who, in their capacity as economic operators, carry out international transport of goods; (d) persons who, in their capacity as economic operators, carry out intra-Community acquisitions and deliveries, imports, and exports; (e) persons who, in their capacity as economic operators, carry out international transport of goods; (f) persons who, in their capacity as economic operators, carry out intra-Community acquisitions and deliveries, imports, and exports; (g) persons who, in their capacity as economic operators, carry out international transport of goods; (h) persons who, in their capacity as economic operators, carry out intra-Community acquisitions
the consignee listed in the import customs declaration, or the consignor listed in the export customs declaration, in the case of goods subject to import or export operations, as applicable.
the beneficiary in Romania, in the case of intra-Community acquisitions of goods.
the supplier in Romania, in the case of intra-Community deliveries of goods.
the depositary, in the case of goods subject to intra-Community transactions in transit, both for goods unloaded on Romanian territory for storage or for the formation of a new transport from one or more consignments of goods, and for goods loaded after storage or after the formation of a new transport on national territory from one or more consignments of goods. The novelty consists of the measure implemented regarding the reporting obligations and the definition of users relating to the international transport of goods, while the provisions regarding the reporting of the transport of goods with a high fiscal risk on national territory remain unchanged, in accordance with Article 8 of GEO 41/2022.
*UIT code:*
To generate the UIT code, users referred to in Article 8(1) and Article 8^1 may declare data relating to the transport of goods in the RO e-Transport System no later than three calendar days before the date declared for the start of transport, but before presenting themselves at the border crossing point at the entrance to Romania or at the place of import, or before the vehicle is actually set in motion, as the case may be (note for users: the consignee listed in the customs declaration, the beneficiary and the supplier in Romania in the case of intra-Community acquisitions and deliveries, both for goods with fiscal risk and for those that are not subject to fiscal risk classification, are required to generate the UIT code, to be made available to the transport operator/driver). Regarding the validity of the UIT code (the provisions of GEO 41/2022 remain unchanged): The UIT code is valid for 5 calendar days, or 15 calendar days in the case of intra-Community purchases of goods, as well as in the case of commercial operations referred to in Article 2(9)(g) and (j), starting from the date declared for the start of transport. The use of the UIT code by the road transport operator beyond its period of validity is prohibited.
*Road vehicle weight*
The categories of road vehicles monitored by the RO e-Transport System are those with a maximum technically permissible weight of at least 2.5 tons, loaded with high-risk goods with a total gross weight exceeding 500 kg or a total value exceeding 10,000 lei.
*Obligations of carriers*
Road transport operators are required to equip transport vehicles with telecommunications terminal devices that use satellite positioning and data transmission technologies referred to in Article 4(1)(b^1), and also to provide drivers with the ITU code received.
Offenses and penalties - applicable from July 1, 2024.
A fine ranging from 20,000 lei to 100,000 lei for legal entities, as well as confiscation of the value of undeclared goods and a fine ranging from 10,000 lei to 50,000 lei for individuals, for: Failure to declare in the RO e-Transport System data relating to the transport of goods with a high fiscal risk (national transport), as well as data relating to all international transport of goods, so that they can be identified by the UIT code (intra-Community/extra-Community import/export) and declaring in the RO e-Transport System quantities different from those that are the subject of the transport of goods.
A fine ranging from 10,000 lei to 50,000 lei for individuals or a fine ranging from 20,000 lei to 100,000 lei for legal entities for:
Art. 8: The transport organizer or transport operator, as applicable, is required to update, during the period of validity of the UIT code, the information regarding the identification of the road transport vehicle whenever it changes, before the vehicle is put back into service (if, when the vehicle loaded with goods with a high fiscal risk is put into service or during transport, the RO e-Transport System is not operational, the reporting obligation provided for in paragraph (1) and the updating obligation provided for in paragraph (1^1) shall be suspended until the system is back in operation – For the situations provided for in paragraph (1^2), the obligations provided for in paragraph (1) and/or paragraph (1^1) shall be fulfilled by the end of the next working day after the system is back in operation, including for completed transports). The RO e-Transport System shall be used to notify the parties involved in the transport of high-risk goods on national territory.
Art. 11 – paragraph 3: It is prohibited to modify the data recorded in the RO e-Transport System regarding the transport of goods after presentation at the border crossing point upon entry into Romania or at the place of import, respectively after the actual movement of the vehicle on public roads, as the case may be.
Art. 12 – paragraph 1: If a consignment of goods includes both high-risk goods and other goods that do not fall within the category of high-risk goods established for this purpose by order of the president of the National Agency for Fiscal Administration, the users referred to in Art. 8 paragraph (1) shall be required to declare in the RO e-Transport System the data relating to the transport of all goods transported in a consignment of goods.
Art. 12 – para. 2: If the documents held by the users referred to in Art. 8 para. (1) letter d) do not show that the goods transported fall into one of the categories of goods referred to in para. (1), they are required to declare in the RO e-Transport System the data related to the transport of all goods transported within a consignment of goods.
Art. 8^2:
The road transport operator is required to ensure the transfer of current positioning data for the transport vehicle, which is subject to declaration, throughout the entire transport route of the goods being monitored by the RO e-Transport System.
The road transport operator is required to equip transport vehicles with telecommunications terminal devices that use satellite positioning and data transmission technologies referred to in Article 4(1)(b^1). The telecommunications terminal devices referred to in Article 4(1)(b^1) are installed in the vehicle’s engine compartment and are equipped with a power supply that is independent of the vehicle’s electrical system.
The provisions of paragraph (2) shall not apply where the positioning data of the transport vehicle is transferred by its devices.
The road transport operator is obliged to provide the driver with the UIT code received in accordance with the provisions of Art. 8 para. (2).
Fine ranging from 5,000 lei to 10,000 lei for:
Failure by the road transport operator to comply with legal provisions (GPS, satellite positioning data transmission terminal equipment + presentation of the UIT code received by the driver):
Art. 8^3: In the case of transport of goods referred to in Article 1(2), the driver of the transport vehicle is required to start the positioning device before starting transport on national territory and to stop the positioning device only after delivery of the goods to the declared place of delivery on national territory or after leaving national territory.
Art. 10, paragraph (1): The driver of the transport vehicle is required to present, at the request of the competent authorities within the National Agency for Fiscal Administration or the Romanian Customs Authority, or at the request of police officers and agents within the Romanian Police, the documents accompanying the transport of goods subject to monitoring through the RO e-Transport system, together with the UIT code provided in accordance with the provisions of Article 8^2(4).
Legal basis:
Government Emergency Ordinance 41/April 8, 2022 – establishing the National System for Monitoring Road Transport of Goods with High Fiscal Risk RO e-Transport and repealing Art. XXVIII of Government Emergency Ordinance No. 130/2021 on certain fiscal and budgetary measures, the extension of certain deadlines, and the amendment and supplementation of certain normative acts
Government Emergency Ordinance 115/December 14, 2023: Articles LXXIV, LXXV - on certain fiscal and budgetary measures in the field of public expenditure, for fiscal consolidation, combating tax evasion, amending and supplementing certain normative acts, as well as extending certain deadlines
ORDER No. 2545/6316/2022 of December 21, 2022 - approving the Procedure for the use and operation of the national system for monitoring the transport of goods with high fiscal risk RO e-Transport.
