vattaxitalyxml

A credit LiPE: the XML format field by field

30 March 2026

In the previous article on LiPE I described the VP section field by field. This time we start from the other direction: a real XML file, for an all-credit situation, and we analyse what the format reveals.

This is the file that gets transmitted electronically to the Agenzia delle Entrate.

The outer structure

<?xml version="1.0" encoding="UTF-8"?>
<iv:Fornitura xmlns:iv="urn:www.agenziaentrate.gov.it:specificheTecniche:sco:ivp"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <iv:Intestazione>
    <iv:CodiceFornitura>IVP18</iv:CodiceFornitura>
    <iv:IdSistema>RSSMRA80A01H501U</iv:IdSistema>
  </iv:Intestazione>
  <iv:Comunicazione identificativo="00001">
    ...
  </iv:Comunicazione>
</iv:Fornitura>

The root namespace is urn:www.agenziaentrate.gov.it:specificheTecniche:sco:ivp — the LiPE format's signature, analogous to the FatturaPA namespace. The second namespace, xmlns:ds referencing the W3C XMLDSig spec, is there for digital signatures: this file can also be electronically signed, though transmission via the AdE portal uses its own sealing mechanism.

CodiceFornitura: IVP18 identifies the submission type. IdSistema is the tax code of the transmitting party — here it matches the declarant, but it could be an intermediary.

The <iv:Comunicazione> tag has an identificativo="00001" attribute that numbers the communication within the submission. A submission can contain multiple communications, but in practice almost always contains just one.

The cover page

<iv:Frontespizio>
  <iv:CodiceFiscale>RSSMRA80A01H501U</iv:CodiceFiscale>
  <iv:AnnoImposta>2026</iv:AnnoImposta>
  <iv:PartitaIVA>12345678901</iv:PartitaIVA>
  <iv:FirmaDichiarazione>1</iv:FirmaDichiarazione>
  <iv:IdentificativoProdSoftware>SOFTWARE GESTIONALE</iv:IdentificativoProdSoftware>
</iv:Frontespizio>

AnnoImposta is the reference year, not the filing year. For Q1 2026, the file is submitted by May 2026 but declares 2026.

FirmaDichiarazione: 1 means the declarant and the subject the communication refers to are the same person. If an intermediary were filing on behalf of a third party, this value would differ.

IdentificativoProdSoftware is the name of the software used to generate the file. It has no effect on validation but is tracked by the AdE for statistics and debugging.

The accounting data: three modules

This file has three modules, one for each month of Q1. Three modules means the subject is a monthly filer — above the turnover threshold — not a quarterly one. A quarterly filer would have a single module.

Module 1 — January

<iv:Modulo>
  <iv:NumeroModulo>1</iv:NumeroModulo>
  <iv:Mese>1</iv:Mese>
  <iv:TotaleOperazioniAttive>106,00</iv:TotaleOperazioniAttive>
  <iv:TotaleOperazioniPassive>290,48</iv:TotaleOperazioniPassive>
  <iv:IvaEsigibile>60,11</iv:IvaEsigibile>
  <iv:IvaDetratta>63,90</iv:IvaDetratta>
  <iv:IvaCredito>3,79</iv:IvaCredito>
  <iv:CreditoAnnoPrecedente>590,21</iv:CreditoAnnoPrecedente>
  <iv:ImportoACredito>594,00</iv:ImportoACredito>
</iv:Modulo>

The first thing to notice: the VP6 field has no fixed name. In the paper form it's "VAT owed or credit" with two columns. In XML it becomes a conditional tag:

If output VAT exceeds input VAT → <iv:IvaDovuta>
If input VAT exceeds output VAT → <iv:IvaCredito>

Here IvaEsigibile (60.11) < IvaDetratta (63.90), so <iv:IvaCredito> appears with the value 3.79. The tag IvaDovuta doesn't exist in the file — it's not present with a zero value, it's absent. The presence or absence of the tag is itself semantic information.

CreditoAnnoPrecedente is VP9 — the residual credit from the previous year's annual VAT declaration. This field appears only in the first module of the year. From the second module onward, the carryforward happens via CreditoPeriodoPrecedente (VP8). This makes sense: the prior-year credit "enters" once, at the start of the year.

ImportoACredito (VP14 col.2) = 3.79 + 590.21 = 594.00 ✓

Here too, the final tag is conditional. If the result were a debt, <iv:ImportoADebito> would appear. The tag ImportoADebito never appears in this entire communication.

Module 2 — February

<iv:Modulo>
  <iv:NumeroModulo>2</iv:NumeroModulo>
  <iv:Mese>2</iv:Mese>
  <iv:TotaleOperazioniAttive>150,00</iv:TotaleOperazioniAttive>
  <iv:TotaleOperazioniPassive>47,19</iv:TotaleOperazioniPassive>
  <iv:IvaEsigibile>37,90</iv:IvaEsigibile>
  <iv:IvaDetratta>10,38</iv:IvaDetratta>
  <iv:IvaDovuta>27,52</iv:IvaDovuta>
  <iv:CreditoPeriodoPrecedente>594,00</iv:CreditoPeriodoPrecedente>
  <iv:ImportoACredito>566,48</iv:ImportoACredito>
</iv:Modulo>

February is different: IvaEsigibile (37.90) > IvaDetratta (10.38), so <iv:IvaDovuta> appears with 27.52. The month has a gross VAT liability.

But the final result is still a credit: the 594.00 carried from January is more than enough. ImportoACredito = 594.00 − 27.52 = 566.48 ✓

This module shows that IvaDovuta and ImportoACredito can coexist: the month closes with a VAT liability, but the accumulated credit absorbs it and the net result remains positive.

CreditoPeriodoPrecedente (VP8) takes exactly the value of ImportoACredito from the previous module: 594.00. This is the carryforward chain that runs through every module in the communication.

Module 3 — March

<iv:Modulo>
  <iv:NumeroModulo>3</iv:NumeroModulo>
  <iv:Mese>3</iv:Mese>
  <iv:TotaleOperazioniAttive>0,00</iv:TotaleOperazioniAttive>
  <iv:TotaleOperazioniPassive>441,27</iv:TotaleOperazioniPassive>
  <iv:IvaEsigibile>6,65</iv:IvaEsigibile>
  <iv:IvaDetratta>62,86</iv:IvaDetratta>
  <iv:IvaCredito>56,21</iv:IvaCredito>
  <iv:CreditoPeriodoPrecedente>566,48</iv:CreditoPeriodoPrecedente>
  <iv:ImportoACredito>622,69</iv:ImportoACredito>
</iv:Modulo>

March has TotaleOperazioniAttive: 0,00 — no sales in the month. This is a valid situation: there can be output VAT (6.65) even without active transactions in the period, for example from deferred-liability operations registered in March but relating to invoices issued earlier.

CreditoPeriodoPrecedente picks up 566.48 from February. ImportoACredito = 566.48 + 56.21 = 622.69 ✓

The credit grows month by month. By the end of the quarter the taxpayer has accumulated €622.69 of VAT credit, to be carried forward to the next quarter or offset against other taxes via F24.

What's missing

Looking at absent tags is as informative as looking at present ones.

VP7 (DebitoPeriodoPrecedente) appears in no module: no month left a sub-threshold debt unpaid.

VP12 (InteressiTrimestrali) doesn't appear: this is a monthly filer; the 1% interest surcharge is reserved for quarterly filers.

VP13 (Acconto) doesn't appear: it's only filled in December.

VP10 and VP11 don't appear: no EU vehicle payments, no special tax credits.

The format doesn't include empty or zero-value tags — inapplicable fields are simply omitted. This keeps the file compact but requires the reader to distinguish "field not present" from "field is zero."

Decimal commas

Numeric values use a comma as the decimal separator (594,00, not 594.00). It's a localisation choice consistent with Italian convention, but unusual in XML where the decimal point is the international standard. Anyone generating or parsing these files programmatically must handle this explicitly — parseFloat("594,00") in JavaScript returns NaN.

What the structure reveals

The LiPE in XML is more readable than the FatturaPA: tags have comprehensible Italian names, the structure is flat, the arithmetic is verifiable line by line. But the design choices leave some things implicit that a more explicit format would declare:

The direction of the balance (debit or credit) is inferred from the name of the tag that's present, not from an explicit field
The filer type (monthly or quarterly) is inferred from the number of modules, not from a declared field
Absent values must be interpreted as zero, not as missing data

These are conventions documented in the technical specifications. But anyone implementing a LiPE parser discovers them the hard way.

This article is informational. For your specific tax situation, consult a qualified accountant.