# E-invoices and NemHandel

EAN/NemHandel sends invoices as e-invoices to a public or private recipient that can receive them. It is a document-delivery method and must be kept separate from payment. An invoice can be delivered through EAN and still be unpaid.

## Enable delivery

Open EAN settings, enable the part of setup the team needs, and save the business details shown. On the customer, enter the EAN or GLN identifier and check which invoice recipient is used. If the customer should receive an email copy as well as the e-invoice, select that separately. Email is not always an automatic fallback.

Create a fictional invoice and check recipient, currency, number, and delivery choice before sending a real invoice. The accounting system's PDF can have a different layout from Alunta's PDF.

## EAN/NemHandel statuses from document to delivery

Follow the invoice delivery status:

- **Pending:** a prerequisite is missing, usually a final customer-facing invoice number.
- **Submitted:** delivery has been submitted to EAN/NemHandel.
- **Transmitted/delivered:** the delivery was transmitted to or marked delivered to the recipient.
- **Failed:** delivery could not complete. Check the recipient and document, correct the problem, and use the displayed retry when it is available.

Paid is a separate payment status. A document can be delivered and still have an outstanding balance.

When the accounting system owns the number, Alunta waits to send the e-invoice until booking provides the final number. Slow booking can therefore leave delivery pending. If delivery cannot be sent, the interface shows an integration issue or the delivery outcome it provides. Do not promise immediate delivery for every team.

## Customer fields

Custom customer fields can map to buyer reference, purchase-order number, accounting code, contact, and delivery date. Create the field in customer settings, fill it on the customer, and select it in EAN setup. Then inspect a new invoice. When no mapped contact field has a value for the customer, a company customer's contact person (Att.) is used, otherwise the customer name.

When both a normal reference and a custom field are filled, the result follows the precedence shown in setup. Mapping applies going forward and does not rewrite documents already created. Turn mapping off when it should no longer apply to new documents.

## Example and questions

Example: “Example ApS” has GLN 5790000000000 and a “Purchase order” customer field. You map it to the purchase-order number, create a new invoice, and check the preview. The invoice is Pending because booking has not supplied a final number; Paid follows later.

Why was email not sent? Check EAN status, recipient, and any wait for a number. Why is the invoice delivered but unpaid? Delivery and payment are separate. Why is delivery date missing? Check field type, customer value, and mapping precedence. Why does the PDF look different? It may have been generated by the accounting system.
## When delivery is pending

First check the customer's EAN/GLN, delivery method, and invoice document number. If the accounting system assigns the number, Alunta may wait before sending. Open integration status when the invoice does not progress. An email copy is a separate delivery option only when enabled and recipient data are usable.

EAN/NemHandel does not determine payment status. A customer can receive the document without paying, or pay while delivery status still needs review. Use payment and delivery status separately.

## Before changing mapping

Test with a synthetic customer, a normal reference field, and a custom field. Save mapping, create a new invoice, and check the preview. Settings apply going forward; an existing invoice needs its own document flow if it must be corrected.

## Payment deadline and terms

Manual invoices using the customer's e-conomic payment terms or e-conomic's PDF wait for verified terms from the booked document. This also applies when Alunta keeps its own invoice number. The final due date is saved on the invoice and used for EAN delivery and reminders; later setting changes do not rewrite a finalized snapshot.

The e-invoice contains the final date and payment terms text. Bank details are included only when saved on the invoice. A delivery variant whose due-date preservation during format conversion has not yet been verified may be held with an integration issue. A delivery receipt proves transport, but does not prove that conversion preserved every payment field.

A correction in Alunta does not change an e-invoice already delivered. A delivered invoice is therefore not automatically resent after a date correction; agree separately how to handle the recipient's document.