Rejected, Pending or Never Delivered? The Three E-Invoice States Your Team Keeps Mixing Up

It is a Thursday afternoon at a food distributor just outside Milan. Giulia, who handles accounts receivable, opens the e-invoicing dashboard and sees a red badge next to invoice 2026/4417. It covers an €18,400 shipment of olive oil to a regional supermarket chain. The badge says "Not delivered." Month-end is a week away, the customer has not paid, and the fix looks obvious. Giulia copies the invoice, gives it a new number, 2026/4502, and sends it again.

Two weeks later the supermarket's payables team calls. They have two invoices for the same shipment sitting in their tax portal, and their system has already scheduled both for payment. Giulia's controller now has to issue a credit note, explain the doubled VAT to the company accountant, and apologise to a customer who was never actually missing anything.

The original invoice had not failed. Italy's national exchange system had checked it, cleared it, and tried to push it to the supermarket's electronic channel. That channel was unreachable, so the system sent back a failed delivery notice and placed the invoice in the buyer's reserved area of the tax portal. Legally, the invoice counted as issued from that moment. The red badge told Giulia that something had gone wrong. It did not tell her what.

The same week, a different invoice on the same dashboard carried an almost identical red badge. This one had been rejected outright by the exchange system because the buyer's VAT number was malformed. Nobody touched it. Everyone assumed it was still working its way through the system. The five-day window to correct and resubmit it under its original number and date closed quietly, and the company ended up issuing the invoice late.

Two red badges. Two opposite problems. One needed a courtesy email and nothing more. The other needed urgent correction. Treating them the same way produced a duplicate in one case and a late invoice in the other.

This is one of the most common e-invoicing mistakes we see at Artificio, and it has very little to do with technology. It is a vocabulary problem. Most teams have one word for "this invoice did not go through cleanly," when the system is actually telling them one of three very different things.

Why three states collapse into one

Most finance teams learned invoicing in the email era. You attached a PDF, pressed send, and the invoice either landed in the customer's inbox or bounced back. Two outcomes, both easy to read. If it bounced, you fixed the address and sent it again. Nobody got hurt.

E-invoicing does not work like that. Between your system and your customer's payables team there are several layers. Your own service provider or access point sits on one side. A tax authority clearance platform often sits in the middle. The buyer's provider sits on the other side, and the buyer's AP team sits at the very end. Each of those layers can send a message back to you, and each message means something different.

The trouble starts when those messages land in your ERP. Most connectors squeeze every possible answer into a single status field. Anything that is not a clean "Delivered" becomes "Error," "Failed," or "Exception." The person looking at the screen sees one color and makes one decision, usually the fastest one available. They send it again.

Three things make the confusion worse.

The messages arrive in different shapes from different places. A technical response comes from the network as a structured file. A notification comes from the tax authority in its own format. A status appears in a supplier portal. An email arrives from a payables clerk who writes "we cannot accept this invoice" in plain language. All four describe the fate of the same invoice, and none of them look alike.

Countries use different words for similar events, and similar words for different events. "Failed delivery" in Italy means something much closer to "delivered to the tax portal instead of to the customer's system." A "rejection" in one country is a technical failure, while in another it is a commercial dispute.

The people reading the statuses are rarely the people who set up the integration. An AR specialist has no realistic way to know which layer produced a given error code. So she treats every red badge as the same thing, because the screen gives her no reason to do otherwise.

Three states, defined in plain terms

Before getting into country rules and status codes, it helps to define the three states in language anyone on the team can repeat back.

Rejected means someone in the chain looked at the invoice and said no. The single most important question is who said it. If the tax authority or the network rejected it, the invoice usually does not legally exist yet, and the job is to fix it and resubmit. If the buyer rejected it, the invoice does exist. It sits in the tax record, and the fix is a credit note followed by a corrected invoice, never a simple resend.

Pending means you sent the invoice and no final answer has come back. Nothing is wrong yet. But pending is not a place where invoices should rest. Every pending status has a clock attached, and when the clock runs out, pending turns into a problem that a named person owns.

Never delivered means the invoice could not reach the buyer. This state also splits in two. Sometimes the invoice never left your side at all, because the buyer's electronic address was wrong or not registered. Nothing legal happened, so fixing the address and resending the same invoice is safe. Other times the invoice cleared the tax authority and only the last step failed. In those cases the invoice is legally issued, and sending a new one creates a duplicate.

Three questions sort almost every case. Does the invoice legally exist right now? Who has to act next? Is a resend safe, or does the invoice need a credit note first?

Think of it like a parcel. A parcel that the post office refuses at the counter because the label is unreadable never entered the mail. A parcel the recipient refuses at the door was delivered and sent back, and you now owe them a different conversation. A parcel left at the local depot because nobody answered the door is not lost at all. It is waiting to be picked up. Sending a second parcel in that last case just means the customer receives two.

Rejected: who said no matters more than the word itself

The word "rejected" appears in almost every e-invoicing system. What it means depends entirely on which layer sent it.

Take the Peppol network, now the backbone of e-invoicing in Belgium, the Nordics, Singapore, Australia and much of the public sector across Europe. Peppol has two kinds of responses. The first is a technical message from the receiving access point that confirms whether the file arrived and could be read. The second is a business message called an Invoice Response, sent by the buyer's organisation. That second message moves through a set of statuses. Acknowledged means the invoice arrived. In Process means the buyer is reviewing it. Under Query means the buyer needs more information. Conditionally Accepted means it is approved with minor points to fix. Approved means payment is next. Paid means it is done. Rejected means the buyer will not process the invoice, and that status is final. The supplier has to act, usually by sending a credit note and a corrected invoice.

There is a catch. Not every buyer supports Invoice Response messages. Some never send them. So for a large share of Peppol invoices, the only answer you will ever get is the technical one, and a buyer's refusal arrives as an email to your AR inbox instead.

Italy works differently. Every domestic invoice passes through the national exchange system before it reaches the buyer. If the file fails the system's checks, you receive a rejection notice, and the invoice is treated as never issued. You can correct the problem and resubmit within five days, keeping the original number and date. Miss that window and you are dealing with a late invoice.

France launched its reform on 1 September 2026. Large companies and mid-sized enterprises now issue invoices through approved platforms, and every business in scope must be able to receive them. Smaller companies follow in September 2027. The French invoice lifecycle keeps a clear line between an invoice rejected by the platform for technical or compliance reasons and an invoice refused by the buyer for business reasons. They are separate statuses because they lead to separate actions.

Poland's national system, KSeF, became mandatory for receiving invoices for all companies on 1 February 2026, and for issuing invoices for almost all companies from 1 April 2026. Inside KSeF the buyer has no button to reject an invoice. Once an invoice receives its KSeF number, it is in the system. If the buyer disagrees with the amount or the goods, the remedy is a corrective invoice. So when a Polish customer emails to say "we reject your invoice," that is a business dispute. It is not a technical rejection, and resending the same invoice does nothing except confuse their records.

Here is how this plays out on a single day at a mid-sized logistics company. Invoice A for €6,250 is rejected by the network because the buyer's VAT number has a missing digit. The invoice never became a legal document. The AR team fixes the digit and resubmits the same invoice, same number. Invoice B for €11,900 is rejected by the buyer because the purchase order number does not match their system. That invoice is legally issued and already in the tax record. The right move is a credit note for €11,900 and a new invoice with the correct PO. If the team handles both invoices the same way, at least one of them ends up wrong.

Pending is a clock, not a state

Pending feels harmless. It sounds like the system is working and you just need to wait. In practice, pending is where invoices go to be forgotten.

Pending actually happens at three different layers, and each one runs on a different clock.

At the transport layer, your provider has accepted the file and is waiting for the network or receiving access point to confirm it. This should take minutes. If an invoice sits here for more than a few hours, something is stuck, and nobody else is going to notice.

At the tax authority layer, the clearance platform is checking the invoice or trying to deliver it. In Italy, the exchange system can spend up to five days trying to reach the buyer before it gives up and sends a failed delivery notice. That is a normal, expected wait. But a dashboard that shows "pending" for twelve days on an Italian invoice is telling you that a notice arrived and was never read.

At the buyer layer, the invoice has been delivered and the customer's AP team is working on it. Statuses like In Process and Under Query live here. Under Query is the one that hides money. It means the buyer is waiting on you.

Here is a pattern that shows up again and again. An invoice for €42,000 goes out on a Monday with 30-day payment terms. The technical confirmation arrives at 10:02 that morning. On Tuesday the buyer's system sends In Process. On Thursday it sends Under Query, with a note asking for the signed delivery note. The AR dashboard rolls Under Query up into "Pending," which reads as fine. Nobody opens it. On day 32 the invoice shows as overdue, the collections team calls, and the buyer says they asked for the delivery note four weeks ago and are still waiting. The invoice was never late because of the customer. It was late because "pending" hid a question.

The fix is simple to describe. Every pending sub-state gets an expected window and an owner. Transport pending gets hours. Tax authority pending gets whatever the local rules allow, five days in Italy for example. Buyer pending gets a window that fits your payment terms, and Under Query gets its own lane with a same-day response target. When a window expires, the invoice stops being pending and becomes an exception with a person's name on it.

Never delivered: where duplicates come from

If rejected invoices cause late filings, never-delivered invoices cause duplicates. This is the state that produced Giulia's €18,400 problem, and it splits into two situations that look identical on most dashboards.

The first situation is an invoice that never left your side. On Peppol, your access point has to look up the buyer's electronic address before it can send anything. If the buyer is not registered, or the identifier on file is wrong, the lookup fails and the invoice never enters the network. Nothing legal has happened. Your job is to find the right identifier or switch to another delivery channel, and then send the same invoice, same number. This is the one case where a resend is exactly the right move.

The second situation is an invoice that cleared the authority but could not reach the buyer. In Italy, this is the failed delivery notice. The exchange system checked the invoice, accepted it, and tried to deliver it. When it could not reach the buyer's channel, it made the invoice available in the buyer's area of the tax portal and told you so. The invoice is legally issued and has been from the start. Your job is to tell the customer where to find it, send a courtesy copy by email, and update their delivery details for next time. Creating a new XML file creates a second legal invoice for the same goods.

The rule that stops duplicates is short. Before any resend, check whether the invoice already has a legal identity. That might be a clearance receipt from the tax authority, an Invoice Reference Number in India, a KSeF number in Poland, or a delivery notice from Italy's exchange system. If a legal identity exists, the invoice is real, and a resend is the wrong tool.

India shows why this matters so much. Every eligible invoice is registered on the government's Invoice Registration Portal and receives a unique Invoice Reference Number. The portal blocks the same invoice number from being registered twice. That sounds like protection against duplicates, and in a narrow sense it is. But when a team believes an invoice "failed," the portal's block pushes them to give the copy a new number, which then gets its own reference number. Now two legally valid invoices exist for one sale. An e-invoice can be cancelled on the portal within 24 hours of generation. After that, the only clean exit is a credit note. A duplicate caught on day three is far more work than one caught on day one.

What the confusion actually costs

It is tempting to treat all this as an operational nuisance. The business impact is bigger than that, and it shows up in three places.

The first is duplicates. A duplicate invoice inflates your revenue and your output VAT until someone spots it. On the buyer's side, it creates a real risk of double payment. Cleaning it up takes a credit note, a reconciliation, a conversation with the tax advisor and often an awkward call with the customer. Customers notice when they receive two invoices for one delivery, and they start to double-check everything you send. That slows down your payments for months.

The second is missed or late filings. An invoice rejected by the tax authority is, in most clearance countries, not a legal invoice. If the team treats that rejection as "still pending," the sale may not be properly invoiced inside the legal deadline. The VAT may land in the wrong period. Penalties for late or missing e-invoices are calculated per invoice in many countries, and they add up fast. On the buyer's side, a customer cannot deduct input VAT on an invoice that does not exist, so they will not pay it. You lose the revenue timing and the cash.

The third is cash. Every invoice parked in a vague "pending" status, especially one sitting Under Query, adds days to your collection cycle. A query nobody reads becomes an overdue invoice nobody understands.

Here is an illustrative example. Take a mid-sized distributor that sends 6,000 e-invoices a month across Italy, Belgium and Poland. Say 3% come back with anything other than a clean delivery. That is 180 invoices a month that need a human decision. If a third of those are cleared-but-undelivered, and half of those get resent by mistake, the company creates 30 duplicates every month. At roughly 45 minutes of combined AR, tax and customer service time per duplicate, that is more than 22 hours a month spent undoing work that should never have been done. And that number does not include the late filings or the slower collections from the rejected and queried invoices sitting in the same pile.

None of this shows up as a line item. It shows up as a busier month-end, a slower close, a few unhappy customers and a tax advisor who bills more hours than expected.

Building a status model that matches reality

The answer is not a better red badge. It is a status model with enough lanes to match what the systems are actually saying.

Start with five questions for every message that is not a clean delivery. Which layer sent this message, the network, the tax authority or the buyer? Does the invoice legally exist right now? Who has to act next, us or the customer? Is there a deadline, and when does it expire? Is a resend safe, or does the invoice need a credit note first?

Then turn the answers into lanes. A practical model has five of them. Rejected by the authority or network, where the invoice is not issued and needs correction inside the resubmission window. Rejected by the buyer, where the invoice is issued and needs a credit note and a corrected invoice. Pending with a clock, where the invoice is waiting at a known layer with a known deadline. Never sent, where the address lookup failed and a resend of the same invoice is safe. Cleared but undelivered, where the invoice is legally issued and needs a courtesy copy and a fixed delivery address.

Next, map every status code from every channel into those lanes. This is tedious work the first time. Pull the code lists from each provider and each country you invoice in, and decide once which lane each one belongs to. A Peppol technical failure, an Italian rejection notice, a French platform rejection and an Indian validation error all go into the same lane. A Peppol Invoice Response of Rejected, a French buyer refusal and a Polish customer's dispute email go into another.

Add a duplicate guard. Before any user or automation can resend an invoice, the system checks for a legal identity. If one exists, the resend button is blocked and the user is shown the right action instead, which is a courtesy copy or a credit note.

Finally, give every lane an owner. Rejections by the authority usually belong to AR or billing, because the fix is in the invoice data. Buyer rejections often belong to whoever owns the customer relationship, because the fix starts with a conversation. Pending invoices belong to whoever set the clock. Cleared-but-undelivered invoices need someone to update customer master data, which is often a different team again.

Where AI agents change the work

Mapping status codes into lanes is the easy part to describe. The hard part is reading the messages in the first place, because they do not arrive in a tidy, uniform format.

A typical AR team receiving invoices into five countries might see structured response files from the network, notification files from tax authorities, status changes inside supplier portals, and plain emails from customers' payables teams. One of those emails might say "please resend, the PO is wrong." Another might say "we never got this." The first is a buyer rejection that needs a credit note. The second might be a never-sent invoice, or it might be a cleared invoice the customer has not looked for in their tax portal. A rules engine reading subject lines cannot tell the difference. A person can, if they have the time and the context.

This is the kind of work Artificio's AI agents are built for. Instead of relying on templates or fixed field positions, the agents read each response the way an experienced AR specialist would. They take in a technical response file, a tax authority notice, a portal status or a customer email, and work out which invoice it refers to, which layer sent it, and what it actually means. They then place the invoice in the right lane, check whether it already has a legal identity, and start the right clock.

From there, the agents route the work. A rejection by the authority goes to billing with the specific field that failed and the deadline to resubmit. A buyer rejection goes to the account owner with a draft credit note and a corrected invoice ready for review. An invoice that cleared but never reached the customer triggers a courtesy copy and a request to update their delivery details. And any attempt to resend an invoice that already has a legal identity gets stopped before it becomes a duplicate.

People stay in charge of the decisions that carry legal or commercial weight. Credit notes, customer conversations and tax questions still go through a human. What disappears is the guessing. Nobody has to interpret a red badge anymore, because the badge never reaches them without an explanation attached.

Every step leaves an audit trail. When a tax authority, an auditor or a customer asks what happened to invoice 2026/4417, the answer is one click away. It cleared on the 3rd, delivery to the buyer's channel failed on the 8th, a courtesy copy went out on the 8th, and payment arrived on the 29th. No duplicate, no credit note, no awkward phone call.

A practical first step: a 90-day status audit

You do not need a new platform to find out how big this problem is in your own business. You need an afternoon and an export.

Pull every invoice from the last 90 days that did not end in a clean delivery. For each one, answer the three questions from earlier. Did it legally exist when the error appeared? Who needed to act? Was a resend safe?

Then count four things. How many invoices were resent? Of those, how many already had a legal identity when they were resent? Those are your duplicates, whether anyone has found them yet or not. How many authority rejections sat in a "pending" or "error" status past their resubmission window? Those are your late filings. And how many invoices sat Under Query, or in a similar buyer status, for more than a week without a response from your team? Those are your hidden collection delays.

Most teams that run this audit find all three problems at once. They usually also find that the fixes are less about software and more about language. Once the team has agreed what "rejected," "pending" and "never delivered" each mean, and who owns each one, the number of bad resends drops quickly, even before any automation goes in.

The badge is a symptom

E-invoicing was supposed to make invoicing simpler, and in most ways it has. Invoices move faster, errors get caught earlier and tax authorities see transactions in close to real time. But it has also added layers, and every layer can talk back. When a business collapses all of that feedback into one red badge, it throws away the information it needs to act correctly.

Giulia did nothing unreasonable. She saw "Not delivered," she knew the customer had not paid, and she did what any careful person would do with the information on her screen. The problem was the screen. A dashboard that had told her "Issued and available in the buyer's tax portal, delivery to their system failed, send a courtesy copy" would have saved her company a credit note, an accountant's afternoon and a customer's patience.

Rejected, pending and never delivered are three different stories about three different invoices. The teams that learn to tell them apart stop creating duplicates, stop missing deadlines and get paid faster. The teams that do not will keep clicking resend.

Artificio uses AI agents to read, classify and route e-invoice responses across networks, tax authority platforms and customer emails, so every invoice lands in the right lane with the right owner. To see how this works with your invoice volumes and countries, talk to our team.