A familiar pattern plays out in many finance and compliance teams. The invoice was issued correctly. The XML passed validation. The Sistema di Interscambio sent back a notification. Then someone notices the status is not what they expected.
At that point, the practical questions start immediately. Is the invoice valid? Who has to act? Do we contact the customer, the commercial team, or IT? Do we resend anything? What will an auditor expect to see six months later when this exception is sampled?
A mancata consegna fattura elettronica should not be treated as a small clerical inconvenience. In a regulated environment, it is an exception event inside a financial control system. The delivery problem matters, but the stronger signal is whether the organisation can show a disciplined response, clear ownership, and verifiable evidence.
The System Event Behind the Delivery Failure Notification
When SdI issues a notifica di mancata consegna, the invoice has entered a state that many organisations misunderstand. Operational teams often reduce it to “the customer did not receive the invoice”. That description is incomplete and leads to weak handling.
The better framing is this. A delivery failure notification is a system event that touches accounting, client communications, auditability, and control design at the same time.
In practice, I see two very different reactions.
One organisation treats the event informally. Someone in accounts exports a PDF, sends a quick email, and marks the issue as closed in a local spreadsheet. The invoice may well be recoverable by the customer, but the organisation has no durable record of who acted, what was sent, and whether the action matched policy.
Another organisation treats the same notification as an exception workflow. It records the SdI message, assigns ownership, logs the external communication, preserves the artefacts, and links the event to an internal control. The immediate outcome may look similar to the customer, but the governance quality is not similar at all.
Why this matters beyond delivery
A mancata consegna fattura elettronica sits at the intersection of operational continuity and evidence. The invoice remains part of the tax process, yet the delivery exception creates questions around traceability, accountability, and the completeness of internal records.
That distinction matters for teams working under formal governance expectations. A control is not just the action that fixes the issue. A control is the combination of trigger, decision, execution, and evidence.
If your team needs a broader operational view of how e-invoicing affects billing and payment cycles, What Is E-Invoicing and How Does It Impact Cash Flow? is a useful companion read because it connects invoice processing to downstream financial operations rather than treating invoicing as an isolated task.
For teams building internal documentation, it also helps to keep the exception process aligned with the wider electronic invoicing operating model. This overview of the Italian ecosystem is a useful reference point: https://audit-ready.eu/blog/hub-fattura-elettronica
Treat the SdI notification as the start of a governed process, not as the end of a failed transmission.
What auditors usually infer
Auditors rarely focus only on whether a single invoice was eventually accessible. They look at whether the organisation behaves consistently when a known exception appears.
A weak process suggests several risks at once. Manual workarounds may bypass logging. Communications may sit in personal inboxes. Ownership may be unclear between finance and IT. Duplicate actions may create reconciliation problems.
A resilient process shows the opposite. The organisation recognises the event, routes it predictably, documents the response, and preserves evidence in a way that another reviewer can follow later without relying on memory.
That is the significance of the delivery failure notification. It is not just a transport issue. It is a test of process integrity.
Diagnosing the SdI Failure Notification
The first mistake teams make is treating every non-delivery message as if it meant the same thing. It does not. The SdI notification carries the signal you need to choose the right action.
A good diagnostic process starts with the notification itself, not with assumptions from the commercial team or the customer. Check the failure reason, the recipient type, and the invoice identifier before anyone sends a courtesy copy or opens a support ticket.
What usually causes mancata consegna
The verified causes are practical and familiar. SdI may be unable to deliver because of an incorrect Codice Destinatario, use of the generic code 0000000 without a valid PEC or with the wrong PEC, a PEC mailbox that is full or inactive, or a non-functioning telematic channel. These scenarios are described in the Italian guidance on electronic invoice non-delivery from TeamSystem: https://www.teamsystem.com/magazine/fatturazione-e-normativa/mancata-consegna-fattura-elettronica/
These are not all “finance mistakes”. Some belong to master data quality. Some belong to mailbox administration. Some belong to integration maintenance.
That matters because the remediation path should identify the control owner behind the failure class. If the issue is a recipient data error, the accounts team may need to correct the registry. If the issue sits in the delivery channel, IT operations may need to investigate the integration path.
A related operational pattern appears in email infrastructure. For example, failures caused by misconfigured SPF records illustrate how a seemingly small configuration issue can cascade into message handling problems. The point is not that SdI delivery equals email authentication. It is that delivery exceptions often start with configuration hygiene, not with document content.
Read the notification as an instruction set
The notification should be parsed into a short internal checklist:
- Identify the affected invoice. Match the notification to the invoice ID, issue date, legal entity, and customer record.
- Classify the recipient type. B2B, B2C, and PA do not follow the same handling path.
- Record the stated failure reason. Keep the original wording or code in your evidence set.
- Check whether retry logic applies. SdI behaviour differs depending on recipient type.
- Decide the next action without resending through SdI. That decision point prevents duplicate handling.
B2B and PA are not the same workflow
The distinction between private recipients and Public Administration recipients is operationally significant.
For B2B and B2C, SdI issues an immediate notifica di mancata consegna when delivery fails. The issuer must notify the recipient through another channel, direct them to retrieve the original XML from the Cassetto Fiscale, and may send a PDF or paper courtesy copy. Guidance for this workflow also states that you should not resend the invoice via SdI, because that creates duplicates. The same source notes that SdI typically retries B2B delivery for 3 days: https://www.ilcommercialistaonline.it/mancata-consegna-fattura-elettronica/
For PA recipients, the protocol is stricter and more formal. SdI retries delivery for 10 days, and if delivery still fails it issues an attestazione di avvenuta trasmissione con impossibilità di recapito. That distinction is outlined in the same TeamSystem guidance already cited above.
| Attribute | B2B / B2C Recipient | Public Administration (PA) Recipient | |---|---| | Initial failed delivery output | Notifica di mancata consegna | Failed delivery followed by PA-specific retry handling | | Typical trigger examples | Wrong codice destinatario, invalid or full PEC, inactive channel | PA delivery path or receiving office issues | | SdI retry period | 3 days according to practitioner guidance at ilcommercialistaonline.it | 10 days according to TeamSystem | | Issuer action | Notify recipient by alternative channel, direct them to Cassetto Fiscale, optionally send courtesy copy | Monitor retry cycle and preserve final attestation if delivery remains impossible | | What not to do | Do not resend the same invoice through SdI | Do not improvise an alternative filing path without preserving SdI evidence | | Final documentary state | MC notice plus issuer communications | Ricevuta di consegna if successful, or final attestation if not |
Good diagnosis is not about speed alone. It is about choosing a response that remains defensible when someone else reviews the file later.
Immediate Remediation and Communication Protocol
Once the failure reason is clear, the organisation needs a response that is both fast and controlled. Ad hoc fixes create most of the downstream mess.
The core rule is straightforward. Upon receiving a notifica di mancata consegna, the issuer must direct the recipient to retrieve the original XML from the Cassetto Fiscale. Practitioner guidance also notes that SdI typically retries B2B delivery for 3 days, while for PA recipients retries extend to 10 days before a final attestation is issued. The same source reports that data entry errors such as incorrect PEC addresses account for 40-50% of failures, and retrieval through the Cassetto Fiscale has a success rate exceeding 90%: https://www.ilcommercialistaonline.it/mancata-consegna-fattura-elettronica/
The sequence that works
A repeatable remediation protocol usually has five steps.
-
Open an exception record
Create a ticket, case, or ERP exception item linked to the invoice identifier. Do this before sending any message externally. If your evidence starts after the customer email, you already have a gap.
-
Preserve the SdI notification
Store the original notification file or message in the case record. Do not rely on inbox retention alone.
-
Notify the recipient through an alternative traceable channel
A normal business email or separate PEC can work, provided the organisation can preserve the message, sender, recipient, timestamp, and content.
-
Send a courtesy copy if useful
A PDF helps the recipient understand what the invoice is, but it is not the legal original. The communication should state that the original XML is available via the customer’s reserved area on the Agenzia delle Entrate portal.
-
Assign follow-up ownership
Someone must verify whether the communication has been sent and whether any customer clarification is still pending.
What does not work
Three responses regularly create avoidable problems.
Resending the original invoice through SdI is the main one. The verified guidance is explicit that the issuer should direct the recipient to the original XML and should not resend via SdI in B2B and B2C scenarios, because duplicate records can result.
Treating the PDF as sufficient is another error. The courtesy copy is useful for communication, not for replacing the original XML path.
Keeping the remediation in personal email only is a control failure. Even if the customer receives the message, the organisation may not be able to prove proper handling later.
A practical communication model
The wording does not need to be elaborate. It does need to be precise.
A sound message usually includes:
- Invoice reference such as number and date
- Reason for contact stating that SdI reported failed delivery
- Instruction that the original XML is available in the recipient’s Cassetto Fiscale in the Fatture e Corrispettivi reserved area
- Courtesy attachment if your process allows a PDF copy
- Internal contact point for questions on registry data or account mapping
A useful operational split is to separate the customer-facing message from the internal root-cause task. The customer needs clear retrieval instructions. The internal owner needs to fix the PEC, codice destinatario, or channel issue so the next invoice does not fail for the same reason.
Escalation rules that reduce friction
Not every case needs the same urgency.
Use a lightweight triage model:
- New customer or first occurrence. Check onboarding data and validate recipient fields.
- Repeat failure for the same customer. Escalate to master data governance or customer administration.
- Multiple failures across customers. Involve IT operations and integration owners. This pattern often indicates a channel problem rather than isolated bad data.
- PA invoice. Keep the case under closer monitoring because the documentary outcome differs and timing matters.
The fastest response is not always the safest one. The best response is the one your team can execute the same way every time, with evidence left behind.
Building an Audit-Ready Evidence Trail
Many teams stop too early. They solve the delivery issue and assume the matter is closed. For audit purposes, that is often the point where significant work starts.
A mancata consegna fattura elettronica can remain valid for VAT purposes and still create a traceability problem. That distinction matters in regulated sectors. Danea notes that this status can create audit gaps under frameworks such as GDPR and DORA, and states that in 2025 the SdI system processed over 2.5 million mancata consegna notifications: https://www.danea.it/blog/mancata-consegna-fattura-elettronica/
The volume matters less than the governance implication. These are not rare, exotic exceptions. They are recurring operational events that need documented handling.
Evidence is not the same as activity
Teams often confuse “we did the work” with “we can prove the work”. Auditors do not accept that equivalence.
A proper evidence set should let a third party answer four questions without interviewing the original operator:
| Question | Evidence needed |
|---|---|
| What happened | The original SdI notification and invoice reference |
| Who acted | Role, assignee, or named owner in the case record |
| What was done | Outbound communication log, attachments, and timestamps |
| Was it completed under control | Closure note, approval record, or linked control test result |
If one of those is missing, the event may be operationally resolved but still audit-weak.
What to retain in practice
For each exception, retain a compact but complete package.
- Original SdI artefact. The notification itself, preserved in its original format where possible.
- Invoice metadata. Invoice number, legal entity, customer, issue date, and internal ledger reference.
- Failure classification. Wrong PEC, full PEC, codice destinatario issue, inactive channel, or other stated cause.
- Recipient communication record. The message sent through the alternative channel, including timestamp and sender identity.
- Courtesy copy evidence. If a PDF was sent, retain the exact file version attached.
- Assignment and closure record. Who owned the task, whether escalation occurred, and when the case was closed.
This package should be centralised. Local folders, inbox archives, and chat screenshots are weak evidence stores because they are hard to retain consistently and hard to export cleanly.
A good evidence discipline also separates operational notes from formal artefacts. Notes can explain context. Artefacts prove execution.
Why immutable records matter
Under governance frameworks, the issue is not only whether evidence exists. It is whether the organisation can show the evidence has not been altered casually after the fact.
That is why append-only logs, timestamped actions, versioned records, and controlled access matter. They reduce the risk that an exception process turns into an undocumented patchwork.
For teams formalising this kind of approach, this guide on organising and defending evidence is a strong reference point: https://audit-ready.eu/blog/audit-evidence
Build the control around the event
The strongest operating model treats invoice non-delivery as a named control, not as a loose finance task.
A useful control design includes:
- Trigger. SdI MC or equivalent final attestation event.
- Owner. Usually finance operations, with IT support for channel issues.
- Required actions. Preserve notification, contact recipient, provide instructions, log completion.
- Required evidence. Defined artefacts, not free-form notes.
- Review method. Periodic sampling by compliance, finance control, or internal audit.
If a control cannot be reconstructed from retained evidence, it is difficult to defend it as an effective control.
The practical trade-off is simple. A richer evidence trail takes more discipline at the moment of handling. But it dramatically reduces audit friction later, especially when the original operator has moved on, inboxes have been archived, or the event sits inside a larger review of financial controls.
Understanding the Legal and Financial Liabilities
A weak handling process does not only create audit inconvenience. It can create direct liability.
For B2B and professionals, if the issuer does not properly notify the client after a non-delivery event and the client must issue an autofattura (TD20) to regularise their position, the issuer faces sanctions of 100% of the tax, with a penalty from €250 to €2,000 per violation under D.Lgs n. 471/1997. The same TeamSystem guidance also notes that for Public Administration invoices, SdI retries for 10 days before issuing the final attestation of transmission with impossibility of delivery: https://www.teamsystem.com/magazine/fatturazione-e-normativa/mancata-consegna-fattura-elettronica/
That point should change how leaders classify the issue. This is not only a customer service problem. It is a control failure with financial consequences.
Where liability sits
The issuer’s duty is not to guarantee that the recipient behaves perfectly. The issuer’s duty is to handle the failed delivery correctly and to notify the recipient that the invoice is available through the proper channel.
If the issuer cannot show that this duty was carried out, the organisation may struggle to defend itself if the issue later appears in a tax review, dispute, or control test.
The legal exposure also interacts with process design. A vague policy that says “finance should inform the customer” is not enough. The organisation needs a concrete rule for who sends the communication, which channel is allowed, how the action is recorded, and where proof is stored.
Financial impact is often indirect first
The sanction is the obvious risk, but many teams feel the damage earlier in less visible ways:
- reconciliation delays between issued invoices and customer records
- disputes over whether an invoice was properly communicated
- duplicated manual work by finance and customer service
- avoidable escalations to advisers or legal teams
These are governance costs, not just tax costs.
For organisations already standardising digital approval and records, adjacent controls such as formal signing practices often help reinforce evidence quality. This practical reference on PAdES signing is useful when reviewing how financial and compliance documents are preserved: https://audit-ready.eu/blog/firma-digitale-in-formato-pades
The key legal lesson
The legal framework rewards disciplined recovery behaviour. It does not reward improvisation.
That is why the strongest response to mancata consegna fattura elettronica is a process that joins tax handling, communication discipline, and evidence retention. Once the event becomes legally relevant, memory and goodwill are poor substitutes for records.
Systematising the Response From Manual to Automated Control
A manual process can work at low volume. It usually breaks under repetition.
The usual failure mode is not that people do nothing. It is that they do the right thing inconsistently. One operator saves the SdI message. Another does not. One uses the approved email template. Another writes a free-text message. One closes the ERP exception. Another leaves it open. The result is variation, and variation is where audit findings grow.
What mature teams automate
The response should be designed as a workflow with explicit control points.
A practical pattern looks like this:
- Inbound trigger. The SdI notification enters the accounting or ERP environment.
- Automatic classification. The case is labelled by recipient type and failure reason.
- Ownership assignment. The workflow routes the item to the right finance or support queue.
- Template selection. The operator gets the approved communication text and required attachments.
- Evidence placeholder creation. The system expects the operator to upload the outbound message or preserves it automatically if integrated.
- Closure criteria. The case cannot be marked complete until the required artefacts exist.
This is automation used correctly. It reduces missed steps, but it does not remove accountability. A human still owns the event. The system makes the expected path harder to bypass.
Controls are stronger than tools
Many teams buy a tool and expect governance to appear by itself. It does not.
An ERP alert, a ticketing rule, or an accounting software integration is only useful if it sits inside a defined control model. That means documented ownership, approved communication paths, minimum evidence requirements, escalation rules, and periodic review.
Three design choices matter most.
Ownership must be role-based
Do not assign this process to “whoever issued the invoice”. That works until someone is absent, changes team, or uses a personal workaround.
Assign the event to a role, queue, or function. Then map named backups for absence coverage.
Data quality must feed back into issuance
If the same customer repeatedly causes MC events because of PEC or recipient registry errors, the system should push that signal back into onboarding or master data management.
Otherwise, the organisation keeps fixing symptoms one invoice at a time.
A short explainer can also help teams align around the workflow concept before they implement it in their own environment:
Testing is part of the control
A control that exists only on paper is not operational resilience.
Run simple simulations. Feed a known failed-delivery case through the workflow. Check whether assignment, communication, evidence capture, and closure all happen as designed. Then review whether a third party could reconstruct the event using only retained records.
Automation should remove repetition and omission. It should not hide decisions or weaken accountability.
What changes when the process becomes systematic
The biggest improvement is not speed. It is reliability.
A systematic process produces consistent customer communications, fewer duplicate actions, cleaner evidence, and clearer escalation. It also gives compliance and internal audit a defined object to review. Instead of sampling random email exchanges, they can test a specific exception control with known artefacts.
That is the maturity shift. Mancata consegna fattura elettronica stops being an annoying side case handled by memory. It becomes a designed business process with predictable outputs.
Conclusion A Test of Process Resilience
The most useful way to look at mancata consegna fattura elettronica is not as a delivery mishap. It is a routine stress test for the organisation’s financial controls.
The event is predictable. The causes are known. The handling path is not mysterious. What varies is whether the organisation responds with a documented system or with a collection of personal workarounds.
Strong teams do four things well. They diagnose the SdI signal correctly. They communicate through a controlled recovery process. They preserve evidence in a form another reviewer can trust. They turn the workflow into a repeatable control instead of leaving it to individual judgement.
That approach matters far beyond invoicing. It is the same pattern auditors, regulators, and risk leaders expect to see across operational controls. A trigger appears. Someone owns it. The response follows policy. Evidence exists. A later reviewer can verify the chain without relying on verbal explanations.
This is why the delivery failure notification deserves more respect than it usually gets. It is small in appearance, but it reveals whether compliance in the organisation is performative or operational.
If your current process depends on inbox searches, local folders, and remembered conversations, the issue is not only invoice delivery. The issue is control design. Fixing that design is what makes the organisation resilient.
If you want a cleaner way to collect, organise, and export evidence for regulated workflows, AuditReady is built for that operating model. It helps teams structure responsibilities, attach evidence to controls, preserve audit trails, and produce review-ready outputs without turning compliance into a spreadsheet exercise.