Exchange System rejections: how to prevent them with API integration

Rejections from the Exchange System (Sistema di Interscambio - SdI) represent one of the most frequent inconveniences for software houses and developers who integrate electronic invoicing into their management software.

When an invoice is rejected, in fact, the problem does not only concern the sent document. It means interrupting a process, managing a correction, making a new submission and, often, intervening manually on activities that should have been completely automated. With increasing volumes, even a few errors can turn into a significant operational cost.

For this reason, designing an API integration also means building a system capable of identifying anomalies before they reach the Exchange System (SdI), minimising rejections and simplifying the management of outcomes.

Let's look at the most common errors and what measures allow them to be prevented already during the development phase.

Why Exchange System rejections occur

Rejections from the Exchange System are the result of checks carried out by the SdI on the received XML file. Before forwarding the invoice to the recipient, the system verifies that the document complies with the technical specifications laid down for the FatturaPA and that all mandatory information is correct and consistent.

In most cases, therefore, the rejection does not depend on a malfunction of the SdI but on incomplete or inconsistent information generated upstream by the software that produces the document.

Let's think, for example, of management software that automatically retrieves customer registry data from an internal database. If the VAT number is incomplete or the recipient code is not updated, the XML file may be formally correct but contain information that prevents the correct processing of the invoice.

For this reason, it is convenient to consider the rejection as the last link in the chain. In most cases, in fact, the problem arises long before transmission.

[H3] The most frequent electronic invoice SDI errors

SDI electronic invoice errors can have different origins, but some recur with greater frequency during the development of integrations. Among the most common we find:

- invalid VAT number or tax code;
- incorrect recipient code or certified email (PEC) address;
- missing mandatory fields in the XML file;
- use of a Document type that is not consistent with the operation;
- incomplete or incorrectly entered DDT references in deferred invoices.

A practical example helps to understand the problem: if an ERP automatically generates a deferred invoice TD24 but does not correctly report the references to the linked DDTs, the document may be rejected or generate subsequent administrative inconsistencies.

Similarly, a customer registry updated only partially can produce documents that are formally well-constructed but destined to fail the SdI checks.

The same principle also applies to deferred invoices: incomplete management of DDT references can cause avoidable errors. We have explored this topic further in our dedicated guide to automating deferred invoices via API. Identifying these anomalies before sending allows you to avoid corrective activities, new submissions, and slowdowns in the entire process.

How to prevent Exchange System rejections before sending

Preventing Exchange System rejections means moving checks inside the application that generates the invoice, instead of delegating them exclusively to the SdI.

This approach reduces the number of rejected documents and allows users to correct any anomalies while the process is still under the control of the management software. Furthermore, it improves the user experience because errors are returned more clearly compared to the technical messages produced by the Exchange System.

To achieve this goal, it is useful to distinguish between formal checks on the XML file and application verifications on the data managed by the software.

[H3] Electronic invoice XML validation: the first check to automate

Electronic invoice XML validation represents the first level of prevention.

Before transmission, it is advisable to verify that the document respects the layout required by the FatturaPA, that all mandatory fields are filled in, and that the file structure complies with the technical specifications.

This check allows for the immediate interception of many of the anomalies that would otherwise only be detected by the Exchange System.

Let's imagine, for example, that an update to the management software involuntarily introduces a change in the XML structure. Without prior validation, the problem would only emerge after the invoice has been sent. With an automatic check, however, the error is identified during the generation of the document, avoiding rejection and simplifying the release of the new software version.

For this reason, validation should be an integral part of the application flow and not an occasional check performed only during the testing phases.

Formal checks before transmission

An API for the formal check of the invoice allows for the extension of validation beyond the simple check of the XML file. Before sending, it is indeed possible to verify the consistency of the information that feeds the document, further reducing the risk of errors. Among the most useful checks are:

- verification of the correctness of the VAT number;
- checking for the presence of mandatory data;
- validation of VAT rates;
- verification of consistency between the Document type and the operation carried out;
- checking for any duplications of the invoice.

Let's think of a software house that handles thousands of documents every day. If a customer registry is modified manually and the tax code is entered incorrectly, the formal check can immediately block the generation of the invoice and report the problem to the operator. In this way, the document never reaches the Exchange System and the process continues without having to manage a rejection later.

Even in high-volume architectures, these checks can be executed automatically, without affecting the end-user experience, but significantly improving the reliability of the entire integration.

Designing an API integration to reduce SDI rejections

Most Exchange System rejections can be avoided even before the XML file leaves the management software. To achieve this, however, validation must not be concentrated in a single final moment: it is best to distribute it throughout the entire application flow.

Every piece of data entered by the user or generated by the software represents a potential point of error. If the check occurs only at the time of sending, identifying the cause of the rejection becomes more complex and the time needed to correct it increases.

A well-designed API architecture therefore introduces progressive checks that verify the quality of data before generating the XML and before transmission to the SDI.

Validate data before XML generation

The first line of defence concerns the application database. Even before building the XML file, it is advisable to verify:

- presence of all mandatory fields;
- correctness of VAT Number and Tax Code;
- consistency between taxable amount, VAT, and document total;
- validity of VAT codes and Document type;
- presence of information required for special cases (reverse charge, self-invoices, credit notes, etc.).

To make these checks automatic, it is possible to integrate specific services for checking tax data. API Verify ID, for example, allows you to check the validity and existence of Tax Codes and VAT Numbers before issuing the invoice, reducing the risk of using incorrect or invalid data.

In practice, the management software should prevent the creation of an incomplete invoice, instead of delegating the check to the Exchange System. This approach also improves the experience of end-users, who receive an immediate and understandable error message, rather than a rejection notification several minutes after sending.

XML validation of the electronic invoice

Once the document has been generated, the technical validation of the XML schema comes into play. At this stage, the file structure, compliance with the FatturaPA schema, correct use of XML tags, presence of mandatory elements, and consistency between the different blocks of the document are checked.

These are checks that intercept many of the most frequent SDI errors without having to wait for the response from the Exchange System. For this reason, an invoice formal control API represents one of the most useful components in an infrastructure dedicated to electronic invoicing.

Automatically manage SDI outcomes via webhooks

Prevention ends with sending, but the process continues. After transmission, the Exchange System returns notifications that confirm delivery or report any problems. In a modern infrastructure, these notifications are not retrieved manually. The most effective approach consists in using webhooks that automatically update the status of the invoice in the management software.

This allows, for example, to immediately inform the user in case of rejection, initiate automatic correction workflows, notify administrators only when necessary, and keep ERP, CRM, and document systems synchronised.

When the number of documents grows, automating the management of outcomes reduces the operational load and makes monitoring much simpler.

Monitoring SDI errors and managing outcomes: why they make a difference

Many integration projects focus their efforts on the invoice sending phase. In reality, when the system goes into production, the most delicate part becomes continuous monitoring.

Let's think of a software house that manages electronic invoicing for dozens of clients. If a rejection goes unnoticed for a few hours, the problem does not only concern one invoice: dozens or hundreds of documents in error can accumulate before someone intervenes.

For this reason, in addition to preventing electronic invoice SDI errors, it is useful to design tools that allow for the rapid identification of any anomalies. A complete API platform should offer detailed logs of every transmission, history of outcomes, unique request identifiers, automatic notifications in case of error, and dashboards to monitor the status of documents.

In this way, the technical team can quickly trace the cause of the problem without having to manually reconstruct the path followed by each invoice. The goal is not only to avoid rejections, but also to reduce the time needed to resolve them when they occur.

How to reduce Exchange System rejections with A-Cube APIs

Preventing Exchange System rejections means designing an infrastructure that checks data before sending, validates the XML schema, automatically manages outcomes, and makes any anomalies immediately visible.

A-Cube's E-invoicing APIs help software houses and developers build this end-to-end process, from invoice generation to monitoring notifications from the Exchange System. This flow can be combined with API Verify ID to check Tax Codes and VAT Numbers before issuance and reduce the risk of errors in registry data.

The technical documentation allows for quick integration of the services, while the sandbox makes it possible to simulate real cases and verify the application's behaviour before releasing it to production.

If you are designing a new integration or want to make your existing one more reliable, try our sandbox and test the entire electronic invoicing flow before go-live.