Focus
Automating deferred invoicing via APIs: operational models and best practices
Sending and automating deferred invoicing via API requires a solid software architecture focused on synchronisation and data integrity. As volumes grow, the manual management of DDTs (transport documents) and the generation of e-invoicing can become a bottleneck. Developers and software-house technicians must propose solutions that reduce errors and meet deadlines. And that can build a flow for transmitting tax data to the Interchange System that is stable and secure. Let’s see how to do this correctly, from the operating model through to handling responses.
1. How to generate deferred invoicing via the A-Cube API
Before going into how to automate deferred invoicing via API, let’s briefly list the regulatory references on deadlines and the general terms for transmission. These are governed by Article 21, paragraph 4 of DPR 633/72 and can be summarised in 3 main points:
the invoice may be issued by the 15th of the month following the actual transaction;
it must refer to one or more DDTs issued in the previous month;
the deadline for sending the deferred electronic invoice coincides with its issue to the Interchange System.
Those developing integrations for e-invoicing must take these dispatch deadlines into account and provide application logic or integrate an API capable of automatically generating the TD24 document on time.
The TD24 code for deferred invoicing identifies the invoice issued after delivery of the goods. In the XML structure of the e-invoice, it is also used to group multiple DDTs from the same month into a single document for sales made for shipments already completed. How does all this translate in terms of developing the management system? When it links at least one DDT to the document, the platform should automatically set the TD24 e-invoice. The ideal flow would work like this:
the management system generates the DDTs;
the DDTs are saved and marked as “billable”;
automation creates the deferred invoice via API;
the XML is validated and sent to the Interchange System.
Those developing solutions for tax documentation can make use of the API A-Cube for e-invoicing. It allows XML documents and TD24 deferred invoices to be generated, transmitted to the Interchange System, notifications and statuses to be managed, and logs and error handling to be centralised. Moreover, it is already set up for archival substitution in compliance with regulations. The API calls for creating standard and simplified invoices are available in the developer guide.
Box - Regulatory reference: Art. 21 DPR 633/72
Article 21 of DPR 633/72 governs VAT invoicing operations in Italy. It establishes the obligation to issue an invoice within 12 days of the transaction and defines the contents of the document, the rules for deferred invoicing (by the 15th of the following month) and for international operations. Paragraph 4 sets out the guidelines for the supply of goods with DDT and states that a single summary invoice may be issued by the 15th day of the month following the month in which the supply took place. This must contain the date, progressive number, party details (VAT number, tax code, address), nature/quantity of the goods or services, rate and amount.
2. How to automate deferred invoicing, link DDTs and perform correct mapping
If you want a complete overview of how to automate deferred invoicing via API correctly, it is worth keeping several best practices in mind. Some concern the XML DDT reference, others the mapping of DDT fields to XML, and others the grouping of DDTs in deferred e-invoicing.
To link DDTs to deferred invoicing, the mapping in the XML file must be carried out correctly according to the following correspondence between fields and tags:
document number: <NumeroDDT>
document date: <DataDDT>
items: <DatiLinee>
quantity: <Quantità>
recipient: <CessionarioCommittente>
An incorrect mapping generates rejections or accounting inconsistencies and can lead to penalties.
Before generating the TD24 deferred e-invoice, you must check that the number and date are filled in, verify the customer master data and its details are consistent, validate VAT rates and check that the DDT has not already been invoiced. This is a pre-validation logic that can avoid subsequent errors.
The grouping of DDTs for e-invoicing via API is achieved by following these steps:
Select all DDTs that belong to the same customer, so as to issue a single invoice for that subject.
Apply a period filter (for example, all DDTs for the month or the week) based on the invoicing policy you adopt.
Build a single FatturaPA XML, and for each DDT included add a <DatiDDT> block at the start of the document (general data/goods/services section, depending on the structure you are using) and the reference to the lines, if required (for example via <RiferimentoNumeroLinea>), so that each invoice line is linked to the correct DDT.
The DDT data that must be included in the TD24 e-invoice are the DDT number, its details and the linked lines. Without this information the DDT deferred e-invoice is not formally correct. If these are not reported exactly, problems may arise such as rejections by the Interchange System, tax disputes from customers and accounting mismatches.
3. Mass sending of deferred invoices and management of SdI responses: some examples
When e-invoicing volumes increase, it is necessary to structure API architectures that guarantee scalability and security. In these cases it is possible to use APIs that allow the mass sending of deferred invoices.
In addition to automating deferred invoicing via API, E-Invoicing by A-Cube allows notifications to be managed via webhooks for invoicing. It is possible to receive alerts on delivery and rejection outcomes and automatically update the document status in the management system. In this way, infrastructure load is reduced.
One of the biggest problems encountered in this area is SDI Error 00404 for deferred invoicing. This is often linked to:
inconsistent DDTs;
missing mandatory data;
errors in the TD24 document type.
The solution lies in the preventive validation of the XML and in checking the correctness of the mapping we discussed earlier. Moreover, these issues can be avoided with centralised error management.
Automating deferred invoicing: the API-ready solution
As we have seen, effectively designing an architecture that allows deferred invoicing to be automated via API can take longer than expected. A-Cube's API solutions allow developers and technicians to improve work efficiency, prevent errors and act in compliance with regulations. In addition, the support team is always on hand to work alongside and support integration and the resolution of any errors. Would you like more information? Write to info@acubeapi.com!
