Customer fields and delivery date on an EAN invoice
Custom customer fields can map to buyer reference, purchase-order number, accounting code, contact, or delivery date. Create and fill the field on the customer, select it in EAN settings, and check the next invoice. Precedence between normal and custom reference fields follows the displayed setup. Mapping applies going forward and does not change existing documents. See the current guide ### Check precedence
Historical retrospective - August 2026 This article was written afterwards and describes the feature as it worked during the stated period.
Custom customer fields can map to buyer reference, purchase-order number, accounting code, contact, or delivery date. Create and fill the field on the customer, select it in EAN settings, and check the next invoice. Precedence between normal and custom reference fields follows the displayed setup. Mapping applies going forward and does not change existing documents. See the current guide (Markdown file, AI agent-friendly)
Check precedence
Fill a normal reference and a custom field with different synthetic values in a test. The value on the new invoice shows which precedence the setup uses.
Test with two values
Fill a normal reference with “A-100” and a custom field with “B-200” on a synthetic customer. Create a new EAN invoice and see which value appears in the preview. Repeat after changing precedence. This tests setup without changing earlier documents.
Applies to new documents
Mapping is saved in team EAN setup and applies to invoices created after saving. An invoice already created must be reviewed with its own fields. If a delivery date is missing, check that the customer has a date and that the field type is accepted by setup.
FAQ and boundaries
A customer field mapped to EAN does not automatically apply to email, local PDF, or documents already created. Check mapping on a new invoice. If the field is empty, the result can be empty or fall back to the normal field according to displayed precedence.
Support scenario
EAN mapping should be tested after changes to field name, type, or precedence. An empty value can leave the result empty even when mapping is active. When the value is correct on a new invoice, delivery status is still separate from payment status.
Check after the action
Use this check during follow-up: note what was visible before the action, perform only the selected action, and check the document or mandate afterwards. Read a status again before informing the customer if it changes later. The retrospective describes the documented milestone; the current guide and interface determine today’s steps. Examples use fictional customers, amounts, and dates.
If the result differs
If the result does not match expectations, keep the visible status and investigate the relevant prerequisite instead of repeating the action blindly. Check currency, date, customer, payment method, and whether the document was already sent or booked. When answering a customer, distinguish what the system recorded from what the bank or recipient has not yet confirmed.
Close the workflow
A safe workflow ends with a new check, not with clicking Save or Send. Open the new invoice, mandate, or payment record and confirm that the result matches the message the customer receives. If confirmation is still missing, describe the status as pending and set the next review point. Record internally what was selected and which status was shown. This makes the next support check concrete and prevents an already accepted delivery, payment, or relation from being treated as new.
The people and AI helpers behind the updates
Bo Møller and Emil Højbjerg are the primary developers behind Alunta. They spend most of their time coding, so they have delegated the wording of these explanations to our AI helpers.
The AI helpers write from the updates we have deployed to the product. Bo and Emil are behind the changes and remain responsible for ensuring the information reflects what was actually released.
