Electronic invoicing is almost always explained from the paperwork side: which form, which deadline, which fine. For whoever has to operate every day, the paperwork is the least of it. What matters is understanding what is happening underneath, because that is where almost every problem comes from.
An electronic receipt is a file with a state
When you issue an electronic invoice you do not print a piece of paper: you generate a structured file, it is digitally signed, and it is sent to the tax authority for validation. SUNAT responds, and that response is what turns the file into a valid receipt.
From there comes the most important idea in the whole matter: an electronic receipt is not just a document, it is a document with a state. Issued is not the same as accepted, and accepted is not the same as accepted with observations. A system that shows you the PDF and not the state is hiding half the data.
The certified provider, and why it exists
Between your system and SUNAT there is usually a certified intermediary. It handles the signature, the format and the dialogue with the authority, and returns the result. It is not a luxury: it is the piece that absorbs the authority's format changes so your system does not have to be rewritten every time a catalog version changes.
What you should demand from your management system is that it stores that result next to the document. If the response lives only on the provider's portal, every future query is an investigation.
Catalogs are the quiet source of errors
SUNAT publishes catalogs with the valid codes for many things: transaction type, reason for a credit note, reason for transfer on a dispatch note, transport mode. Each has its own domain of values, and they are not interchangeable even when they look alike.
The classic mistake is sending a correct code from the wrong catalog. The document goes out, the system does not complain, and the rejection arrives later. That is why a management platform should keep the catalogs up to date and offer them as a closed list, not as a free text field where somebody types what they remember.
What to do when the submission fails
It fails. The connection drops, the provider is in maintenance, a customer field is incomplete. What matters is not avoiding the failure, it is what remains when it happens: the document has to exist before the submission attempt, its state has to be visible in the list, and the retry cannot consume a second number from the series. If the failure forces you to redo the sale from scratch, the technical problem becomes a cash problem and a queue at the counter.
What XEN does with a pending, rejected or offline receipt is answered, question by question, in the help center. See the answers about receipts
Invoice, boleta and notes: what each is for
The invoice is issued to whoever needs to claim tax credit and requires the buyer's tax identification. The boleta is issued to the final consumer. The credit note corrects or cancels a receipt already issued, and the debit note increases it. None of the four is replaced by editing the original document: once accepted, the original is never touched again.
That is why a well built system does not let you edit a submitted invoice. It is not the software being rigid: it is that the document already exists outside your system.
What you should be able to answer at any moment
If your system is set up well, these questions are answered in seconds and without calling anyone: how many receipts I issued this month, how many are still pending with SUNAT, what the reason for the last rejection was, and which series each till is using. If any of them requires opening an external portal or a spreadsheet, there is your gap.
Electronic invoicing is not hard to understand. It is hard to sustain when the system treats the receipt as a printout and not as what it is: a living document with a state that another institution also knows.
