Italian compliance
Italian compliance is included, in every configuration
Delivery notes, VAT registers, the year-end statutory stock valuation, lot traceability, an electronic invoice checked before it leaves: all of it on in every configuration, from day one. A customer who takes only the warehouse carries the same legal duties as one who takes everything, and meets them with the same software.
Delivery notes, VAT registers, statutory stock valuation, lots and invoicing are part of the product: no module to switch on, no add-on to renew.
Reason from a closed list, outward appearance of the goods, packages, weight, date and time transport began.
The XML you actually issued goes through the official checks that can be run in-house, before the tax authority gets a chance to reject it.
Stock rebuilt at 31 December, valued at real cost from the FIFO layers, and never rewritten afterwards.
In most systems Italian statutory duties are bolted on top: a tax module sold separately, an export handed to another program, a spreadsheet someone fills in at month end. Here it works the other way round. The document comes out of the fact — the delivery note out of the shipment, the invoice out of the order lines, the year-end valuation out of the warehouse cost layers — which is why it cannot be switched off: removing it would mean removing the fact.
The delivery note, with all five elements the law asks for
In Italy goods travel with a delivery note (DDT), and the law names five things it must carry. CargoNode generates it from the shipment, not from a separate screen. The transport reason comes from a closed list of six values, because the reason drives the tax treatment: as free text, a slightly wrong wording leaves a blank field on a legal document, and that note also drops out of the list of notes waiting to be invoiced. Alongside it sit the outward appearance of the goods, the number of packages, the weight, and the date and time transport began. Numbering runs per document type, warehouse and year, assigned atomically: two shipments closed in the same instant get two different numbers and the series has no holes. Goods moving inside your own business are born numbered too: a transfer between two of your warehouses takes a running number of its own from the TRANSFER series, a supplier return from the SUPRET series, off the same atomic counter. That number is what lets you find goods travelling between your depots and reconcile what arrives against what left; the delivery note carrying the five elements, on the other hand, comes out of the shipment to a customer.
- Reason from a closed list: sale, return, goods on approval, subcontract work, consignment, free of charge
- Outward appearance of the goods, package count, weight, date and time transport began
- Numbering per warehouse and per year, assigned atomically: no gaps, no duplicates
- Transport by sender, by recipient or by carrier, with the carrier’s details
- A delivery-note register you can slice by date, warehouse, customer and number
- Transfers and supplier returns are born with a running number of their own, TRANSFER and SUPRET series, off the same counter
- REASONsalefrom a closed list of six
- APPEARANCEboxesoutward appearance of the goods
- PACKAGES3 packages · 12.40 kgreal weight, not estimated
- TRANSPORTby carrier · 12/03 at 16:40transport began
Numbering runs per document type, warehouse and year, assigned atomically: two shipments closed in the same instant get two different numbers.
| What leaves | Series | When it takes its number | Is it a DDT? |
|---|---|---|---|
| Shipment to a customer | DDT | when the shipment is closed | yes, with the five elements the law asks for |
| Transfer between two of your warehouses | TRANSFER | when the transfer is created | no: a movement running number |
| Return to a supplier | SUPRET | when the return is created | no: a movement running number |
The electronic invoice, and who carries it to the tax authority
Italy requires every invoice to be filed electronically in a fixed XML format through the Exchange System, the tax authority’s clearing house. The XML is composed from the document lines — taxable amounts, rates, taxes, customer details — not retyped into a form. Where the rate is zero an exemption code is mandatory and is never guessed: a line without it blocks issuing, rather than leaving and coming back rejected. Before sending, a pre-check re-reads the XML you actually issued and applies the official checks that can be verified without the authority: line amounts and totals, consistency between taxable amount and tax, rates written as percentages, dates, closed lists. Every finding carries the official check code next to it, so you know what to fix.
- XML composed from the document lines, with taxable amount and tax per rate
- Exemption code mandatory below zero per cent: a line without it does not leave
- Pre-check on the issued XML, each finding tagged with its official check code
- Receipts come back and move the status: accepted, rejected, undelivered
- The transmitted XML is frozen with its fingerprint: you know which bytes went out
- Credit notes, partial ones included, linked to the invoice they come from
- 00423Line total is 122.00 but price times quantity gives 120.00line 3
- 00400Zero rate with no exemption codeline 7
- 00424The rate reads 0.22: if you meant 22%, write 22.00line 9 · warning
- OUTCOME2 errors and 1 warning, before filingeach with its official code
These are the official checks that can be run on your own numbers and on the structure of the file, before the authority runs its own: everything that depends on how the document is written shows up now, with the check code next to it. The checks only the authority can run — the VAT number in the tax register, the validity of the signature — stay with it.
Filing to the tax authority: one command, or your own route
Connect the provider and the invoice leaves from here with one command, receipts come back on their own to a dedicated return address, and the document status stops being an assumption — and that contract brings the ten-year legal archiving, which the provider carries with it. The digital signature stays off, and not by oversight: CargoNode always issues the private format and never invoices the public administration, so the signature is never required and the only effect would be paying more per invoice. Carry on as you do today and you download the XML — already through the pre-check — and file it your own way, through the authority’s portal, by certified email or through your accountant: the transmission is still recorded here, with its channel and date. Either way the transmitted XML stays frozen with its sha256 fingerprint, so you can always show which bytes left; and a refiling after a rejection is a new line, never a correction of the earlier one.
- Provider configured per customer: one command to send, receipts coming back
- Without a provider: you download the already-checked XML and file it your way, the transmission still recorded
- The channel — by hand or through the provider — stays next to every transmission
- With the provider comes ten-year legal archiving; the digital signature stays off because it is never required and would cost per invoice
- The transmitted XML stays frozen with its sha256 fingerprint, either way
- Test and live are a property of the installation, never a checkbox in a request
- The linesORDERTaxable amounts, rates and taxes come from the document, not from a retyped form.
- The XMLFatturaPABelow zero per cent the exemption code is mandatory: without it the line does not leave.
- The pre-checkIN-HOUSEThe official checks that can be run without the authority, each with its own code.
- FilingTWO WAYSThrough the connected provider, or by hand: both are right below.
- The outcomeRECEIPTAccepted, rejected or undelivered, with the authority’s protocol number.
The fourth step has two ways — and one thing stays outside
- Provider connectedThe invoice leaves with one command and receipts come back on their own, to a dedicated return address.
- No providerYou download the XML and file it your way: the transmission is still recorded, with its channel and date.
- Signature and archivingOutside our perimeter: the provider does them, and only for whoever connected automatic filing.
VAT registers and what your accountant gets
Sales register, purchase register and daily takings register, with the breakdown per rate on every document and not just a total at the bottom. The two dates stay apart, because they are two different facts: when the transaction happened and when it was recorded. The accountant export is cut by period and comes as two files — the documents and their lines per rate — so a quarter is handed over without anyone retyping anything. The registers do not depend on any module. The periodic VAT settlement, which is a further step because it posts the balances to the journal, lives instead in the Accounting module together with double-entry bookkeeping.
- Sales register, purchase register and daily takings register
- Breakdown per rate on every document, not only the total
- Transaction date and recording date kept separate
- Accountant export cut by period: documents and lines
- The registers stay on in every configuration, as a product invariant
- The periodic settlement posts to the journal and lives in the Accounting module
| Register | What it records | Module needed |
|---|---|---|
| Sales | invoices issued, with taxable amount and tax per rate | none |
| Purchases | invoices received, with their recording date | none |
| Daily takings | transactions with no invoice, day by day | none |
| Periodic VAT settlement | the period balances, posted to the journal | Accounting |
When there is no invoice: the daily takings register
On online sales to consumers an Italian seller owes no invoice unless the customer asks for one, but the transaction must still be recorded. This is exactly where systems that only know invoices lose revenue on the way: money comes in, no invoice exists, and the books carry a hole someone chases at year end. Here the transaction goes into the daily takings register, and money taken before the sale is certified sits on a customer advances account until it is — which is also the right treatment for a deposit received before delivery.
- A daily takings register alongside the sales and purchase registers
- Online store orders are recorded even with no invoice
- Money taken before certification sits on customer advances
- Daily takings carry their own distinct posting reason
- The register is compliance: it is not behind a module
- INVOICES3 customers asked for onethey go out as invoices
- TAKINGS97 transactions with no invoicerecorded under their day
- ADVANCESmoney taken but not yet certifiedcustomer advances account
- REVENUE100 out of 100no pointless documents
The hole someone chases at year end starts right here: a hundred payments, three invoices, and the ninety-seven in between that nobody recorded.
The year-end stock valuation, priced and frozen
The statutory year-end inventory is not a printed list: it is a dated document that has to add up with itself and with the books. It is frozen after the financial year closes, with stock rebuilt as at 31 December and valued at real cost from the goods-in layers — not from a guess at the last price paid. And it is irreversible by design: issued once, never rewritten. That is why the command refuses a year that has not ended, which would produce a document dated 31 December but built on movements up to today, and refuses an empty inventory, which nearly always means the wrong year or history not loaded yet.
- Stock rebuilt as at 31 December from the movements, not from today’s balance
- Valued at real cost from the FIFO goods-in layers
- The header total is the exact sum of the lines underneath it
- The current year is refused: such a document would be wrong and final
- An empty inventory is refused: it is almost always a slip of the finger
- Once frozen it is immutable, and repeating the command returns the same document
- LINESone line per item, warehouse by warehousestock as at 31 December
- VALUEat real cost from the goods-in layersnot the last price paid
- REFUSESthe current year, and an empty inventorythe two slips of the finger
- REPEATthe same command returns the same documentimmutable
The header total is the exact sum of the lines underneath it: frozen once, never rewritten.
Lots, expiry dates and the chain of who got what
A lot belongs to the product and carries two dates that must not be confused: the expiry date, which is hard, and the best-before date, which is a warning. Both have been in the model since day one, together with the supplier the lot came from, because traceability is compliance and not an advanced feature. Allocation orders by nearest expiry, from the availability figure all the way to the pick line. And since every ledger movement carries its lot and serial, the question “where is it today and who did it go to” is answered by filtering the ledger: there is nothing to reconstruct by hand.
- Lot, expiry, best-before and supplier captured at goods-in
- Hard expiry and best-before kept apart: they block different things
- FEFO allocation: the shortest shelf life leaves first
- Serial numbers where the goods need them, from receipt to shipment
- Lot and serial on every line of the movement ledger
- Lot traceability is not a module: it is always on
- EXPIRY12/2026hard: it blocks the way out
- BEST BY06/2026best-before: it warns
- SUPPLIERcaptured at goods-in, together with the lotwho it came from
- FEFOthe shortest shelf life leaves firstfrom availability to the pick
Expiry and best-before are two different dates and they block different things: keeping them on the same field is the classic way to get it wrong.
Margin scheme and consumption duty
Second-hand goods are sold under the margin scheme: the customer is shown no VAT — the line carries the matching exemption code — but the seller still owes VAT on the margin between price and cost, and extracting it needs a second rate next to the first. Two different numbers on the same line, and keeping only one of them is the classic way to get it wrong. The consumption duty on rolling papers, tubes and filters is a different animal again: it is paid on the pieces inside the pack, not on the pack, and that number appears nowhere in the item name. It is declared once on the format, applies to every variant that uses it, and the rate is dated because it changes over time.
- Configurable rates carrying the exemption code for untaxed transactions
- Margin scheme: the code shown to the customer and the rate used to extract the margin
- Consumption duty computed on the pieces in the pack, not on the pack
- Pieces per unit declared on the format, units per pack on the variant
- Dated rates: a change in the law does not rewrite documents already issued
- On the invoice the duty follows its goods line and copies its rate and code
| Line | What the customer sees | What the seller owes | What it is computed on |
|---|---|---|---|
| Standard rate | the tax shown on the invoice | the same tax | the taxable amount of the line |
| Margin scheme | no tax, with the exemption code next to it | VAT extracted from the margin | the difference between price and cost |
| Consumption duty | the duty next to its own goods line | the duty to be paid | the pieces inside the pack |
Where your tax history starts here
Anyone arriving from another system brings years of orders, customers and movements, and wants them in: they carry the customer history, the stock turnover, what things used to cost. But those documents were issued by somebody else. That is why the tax perimeter is a date declared per customer: before it, imported data stays readable and generates no new document; after it, CargoNode issues the documents under a numbering of its own that begins at one. So two systems never number the same year.
- A tax perimeter start date, declared per customer
- Imported history stays readable but produces no new documents
- New numbering starts clean, per warehouse and per year
- Historical orders and movements keep their real dates in the ledger
- No renumbering of documents another system already issued
- You import the historyYears of orders, customers and movements come in with their real dates.
- You declare the start dateThe tax perimeter is a date, and it is declared per customer.
- Before that dateThe data stays there to consult — history, turnover, prices charged — and generates no document.
- From that date onCargoNode issues the delivery note and the invoice, under a numbering of its own that begins at one.
Frequently asked questions
If I only take the warehouse, can I still issue an invoice?
Yes. Invoicing, delivery notes, VAT registers, statutory stock valuation and lot traceability are on in every configuration: there is no module to switch on and none to switch them off. The modules hold other things — double-entry bookkeeping with purchasing, analytics, third-party logistics. The boundary is written in the code, not in a sales promise.
And goods I move between my own two warehouses?
The delivery note carrying the five elements is issued by the shipment to a customer. A transfer between two of your own warehouses takes a running number of its own instead, in the TRANSFER series: that is what you find goods in transit by, what reconciles the arrival against the departure, and what you search on months later. If a shuttle between two of your depots has to travel with a delivery note alongside it, today you draw that one up outside — and the transfer number to reconcile it against is already there.
Do you file invoices to the Italian tax authority yourselves?
The invoice leaves from here: you connect the filing provider with your own credentials, and from then on sending is one command, with the receipts coming back on their own onto the document status. If you would rather carry on as you do today, you download the XML that has already been through the pre-check and file it your own way — through the authority’s portal or through your accountant — and the transmission is still recorded here, with its channel and date.
What about the ten-year archiving of documents?
The filing provider carries it, for customers who connected automatic filing: it travels with that contract, along with the receipts. The brick we lay is there either way: the transmitted XML stays frozen here with its sha256 fingerprint, so you can always show which bytes left.
We also sell second-hand goods: is the margin scheme handled?
Yes, and handled the way it actually works. The margin rate carries the right code towards the customer, who sees no tax on the invoice, and keeps next to it the rate used to extract the margin and compute the VAT you owe. Both live on the same document line and neither gets lost on the way.
We have three years of documents in the old system: how do we move?
You import the history and declare a tax perimeter start date. Before that date the data is there to consult — customer history, turnover, prices charged — and generates no documents; after it, CargoNode issues them. Invoices already issued stay where they are: they are not renumbered and not rebuilt here.
Who can see my company’s data?
Every customer has a separate database schema: there is no query filtering data by customer, because two customers’ data never sits in the same table. People’s access goes through roles and permissions checked by the server — the frontend hides buttons, the backend decides — and sensitive operations stay written in an audit trail that is appended to, never rewritten.
Let us run it on your own documents
Send us a delivery note and an invoice the way you produce them today, with your numbering and your rates. We will show you how they come out of CargoNode and what would change on Monday morning.
Talk to us