The Email Receiver (also called Trusted Sender) is one of the most used apps on the eConnect platform. With it you manage which email addresses may submit invoices to your organisation, configure how those invoices are processed, and even have invoices sent automatically via Peppol. You open the app via Email Receiver in the side menu, under Apps.

Each organisation in your environment gets a unique email address where invoices can be submitted. You find this address in the sidebar under All at the trusted senders.

Navigation for new customers: after registration you land on the environment/account management view. The Email Receiver is not directly visible here. Click Apps → Email Receiver in the menu to open the overview. Under All you will find the automatically created receiver email address of your organisation.

When you open the Email Receiver, you see the dashboard with three overview charts showing the processing status:

• By status: how many documents were successfully processed, in progress or failed
• By status per organisation: the same distribution broken down per organisation in your environment
• By document context: distribution by document type (purchase invoice, sales invoice, expense claim)

These charts give you at-a-glance insight into how email processing is performing.

The Email Receiver app has its own navigation structure in the sidebar:

• Dashboard: the overview with the processing charts
• New sender: add a new trusted sender
• Trusted senders: all configured senders, filtered by status
  • All, Drafts, Invited, Active, Inactive
• Search senders: quickly find a specific sender

Below the dashboard you find the list of all configured email senders. Each sender goes through a status workflow:

To move a sender from Draft to Active, click Update status at the relevant sender.

Tip: you can whitelist a specific email address for maximum security, or an entire domain (e.g. @econnect.eu) if you expect invoices from multiple addresses within that domain.

With the Search senders function you can quickly find a specific sender by email address, domain or organisation name. This is useful when you have many senders configured.

For each sender you can configure the following settings:

Determine which file types the sender may submit:

• E-invoices only (XML): the platform validates the XML and processes it directly.
• Digital invoices only (PDF): the platform converts the PDF via IDR conversion (Scan & Recognise) into a draft e-invoice.
• Both: the platform automatically detects whether it is a PDF or XML and applies the appropriate processing.

The Document Context determines the type of document created during processing: Purchase invoice, Sales invoice or Draft invoice. This setting is passed to the Conversion Task and to the IDR (document recognition). The IDR uses the context to determine which organisation the invoice is intended for. If you set the context to Purchase invoice for your organisation, the IDR knows that your organisation is the recipient and excludes it as a possible sender.

When this option is enabled, valid XML files are automatically sent via Peppol to the recipient, without any action required. Invalid XML is saved as a draft invoice for manual review.

This is a powerful option for organisations that deliver invoices from their software as UBL files by email and want them sent without intervention.

Set per sender whether you want to receive a confirmation:

• On successful processing: you receive a delivery confirmation by email.
• On errors: you receive a notification if processing fails.

The delivery confirmation is sent to the sender's contact email address. Want to disable delivery confirmations? Go to the trusted sender and untick Notification on receipt via email.

The setting Populate supplier email address based on determines how the platform identifies the sender address of the supplier:

• Sender (From): the default sender address of the email (recommended for most situations).
• Reply-To: the reply-to address. Useful for SaaS platforms like Harvest or Moneybird, where the From address is a generic platform address.
• Accept All: accept invoices from all addresses. Only use this in combination with a unique submission address.

You can restrict which organisation in your environment may submit invoices via a specific sender. This is useful when you have multiple organisations in your environment and want to prevent invoices from ending up at the wrong organisation.

For additional security you can require that incoming emails are sent via a secure connection (SSL/TLS). This prevents unencrypted emails from being accepted.

When the platform performs a system action via the Email Receiver (such as creating a draft invoice, a workflow status change or an invoice update), this action is attributed to the most recently appointed administrator of the organisation. This is not necessarily the first administrator, but the user who most recently received the administrator role.

If the administrator role is revoked from that user, ownership automatically falls back to the previous administrator.

Tip: do you see documents attributed to a different user than expected? Check who the most recently appointed administrator of the organisation is. The platform always attributes system actions to that user.

Each email receiver can whitelist one domain. If an organisation needs to receive invoices from multiple domains, create a separate email receiver address for each domain. This is a deliberate design that combines flexibility and security.

With administration detection (also: multiparty conversion), the IDR automatically determines which administration or organisation within an account an incoming PDF invoice is intended for, even when it was submitted via the email receiver of another organisation in the same account. After conversion, the document is delivered to the correct inbox. The terms administration and organisation are used interchangeably here; an administration does not necessarily have to represent an organisation.

• Requires a subscription in which the feature is allowed (Professional as a minimum) and is named separately in the contract.
• Feature pack of the subscription, IDR Features tab, option Allow multi party for IDR conversion.
• On the email receiver: option Conversion for multiple organizations. Only email receivers with this option enabled support multiparty conversion; other receivers continue to work as standard.

Important: the feature-pack setting and any additional IDR configuration are applied by eConnect. Contact sales to have multiparty activated correctly. Contact our sales team.

The organisation of the email receiver is the default. The IDR also receives the details of the other administrations in the same account or environment. When there is a better match with another administration, the invoice is placed on that administration. When in doubt, the default (email-receiver organisation) remains.

Selection runs in two phases: first by the IDR (document recognition), then by the platform itself.

Phase 1: IDR recognition

1. Identifier matching (highest priority): the IDR looks for identifiers such as VAT numbers and chamber-of-commerce numbers. On an exact match, that organisation is selected immediately.
2. Soft matching: if no identifier is found, the IDR looks at organisation name, city and postcode. With exactly one match, selection is automatic. With multiple matches, the document is sent to Quality Control for manual verification.

Phase 2: platform routing

After receiving the XML, the platform looks at the field AccountingCustomerParty/Party/PartyLegalEntity/CompanyID (CompanyID). If this value matches an organisation in the platform, the invoice is placed there. If there is no match, the invoice falls back to the organisation that owns the email receiver.

Only organisations that are part of the same environment or account are eligible. When the recipient on the invoice differs from the platform administration but matches another administration in the environment, the customer party can be corrected. If no administration matches, the email-receiver organisation remains the customer party.

Tip: keep full identifier details (VAT number, chamber-of-commerce number) for all organisations in your account. Also keep names, addresses and postcodes up to date for the most reliable matching.

• Correcting invoices that were sent to the wrong email address within the account.
• Customers who want one email address for all their organisations (the customer must be able to correct misassigned invoices afterwards).

The Email Receiver is not only intended for receiving invoices. With the XML auto-send setting you can also use the Email Receiver to send invoices via Peppol.

It works as follows: you send a valid UBL XML invoice by email to the Email Receiver submission address. When XML auto-send is enabled, the platform validates the invoice and sends it automatically via Peppol to the recipient.

This is a low-barrier way to send invoices via Peppol without a direct API connection or software integration. It is especially useful for organisations that export their invoices as XML from their accounting software and want them sent without intervention.

Important: only valid XML files are sent automatically. Invalid files are saved as draft invoices, so you can correct and send them manually.

When processing BIS 3.0 XML files via the Email Receiver, there are a few points to be aware of:

• Due date (DueDate): the field cbc:DueDate is currently not populated when processing BIS 3.0 XML. This is a confirmed bug.
• Recipient organisation ID (CompanyID): is only populated if the source file contains a value in AccountingCustomerParty/Party/PartyLegalEntity/CompanyID.
• The "Send via" field is correctly carried over.

If a supplier sends both an XML and a PDF attachment in the same email, both attachments are offered for processing. If the XML attachment contains a validation error — such as a BR-AE-10 Reverse Charge error — the XML is rejected and the contact email address receives an error notification. The PDF attachment in the same email is processed normally.

This error notification cannot be suppressed as long as the PDF is being processed: the XML is submitted for validation and fails. If a supplier structurally sends both XML and PDF but only the PDF is desired, support can configure the email receiver to process digital invoices only (PDF). The XML attachment is then no longer submitted for validation and the error notification disappears. Contact support for this.

Tip: for Belgian recipients you can enable auto-send and address invoices to the KBO number (schemeID 0208) instead of the VAT number.

The presence of a spreadsheet attachment does not block processing of the PDF invoice, provided the file is in a supported format and no larger than 5 MB. Behaviour per scenario:

• Supported format + not larger than 5 MB (.xlsx, .ods, .csv) -- the file is added as a secondary attachment to the invoice (not sent to IDR); the PDF invoice is processed normally.
• Supported format + larger than 5 MB -- the entire email is rejected with a bounce email.
• Unsupported format (.xls, .doc, .docx) -- processing is not possible.

Supported MIME types: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xlsx), application/vnd.oasis.opendocument.spreadsheet (.ods), text/csv (.csv). Not supported: application/msword (.doc), application/vnd.openxmlformats-officedocument.wordprocessingml.document (.docx), application/vnd.ms-excel (.xls).

The Email Receiver classifies attachments from an incoming email and determines which document is the invoice and which are attachments. eConnect checks each submitted document individually. Documents are merged in the order of submission: the first document becomes the first page of the invoice, even if that is an attachment. Once a file is recognised as an attachment, all subsequent files in the same email are also treated as attachments.

With multiple PDF files submitted:

• One file recognised as invoice, others are different document types -- the other documents are treated as attachments and added to the invoice.
• Multiple attachments recognised as invoice -- the system cannot determine which attachments belong to which invoice. The attachments are rejected and the sender receives an error message by email.

Page rotation: pages are not automatically rotated. The customer is responsible for the correct orientation when submitting.

Merging attachments: the platform offers the option to merge all attachments in an e-invoice into one PDF.

Generate PDF from XML: there is an option to automatically generate a PDF from the XML invoice. This can be set to: always, never, or only if no PDF yet exists. This can be combined with the merge option.

Submitted PDF unchanged: eConnect only handles the translation and processing. The submitted PDF file itself is not modified (a PDF can be generated via the PDF generation feature).

For organisations that do not allow email forwarding (for example due to IT policy), eConnect offers a direct connection with an Office 365 mailbox. This lets the platform read invoices directly from the connected mailbox, without emails needing to be forwarded.

This is mainly relevant for organisations with strict IT security rules that do not allow automatic email forwarding to external addresses.

Important: the Email Receiver feature requires at least a Basic subscription. With the free Invoice Portal this feature is not available.

Organisations that process more than 1,000 messages per day through an O365 mailbox connection may find that the Office 365 mail server blocks incoming emails. The typical error message is: "The recipient has exceeded their limit for the number of messages they can receive per hour."

This can happen, for example, with large batches of invoices and their associated status emails. The solution is to add the eConnect IP addresses as trusted senders via the Exchange Admin Center (EAC) as an Office 365 Administrator.

Follow these steps:

1. Go to the Exchange Admin Center and open Mail flow > Connectors.
2. Create a new connector from Partner organization to Office 365.
3. Configure the connector to treat email from the IP addresses below as trusted.

Important: without this configuration the rate limit remains active and incoming emails are rejected as long as the volume is above the O365 threshold. Contact your IT department if in doubt.

The platform has two different flows for email addresses that customers sometimes confuse:

1. Add an extra email address to your account: this determines which email addresses you can use to log in and submit. Read more in Add an extra email address.
2. Add a trusted sender in the Email Receiver: this determines which external email addresses may submit invoices to your organisation. That is what this article describes.

If you are unsure which option you need: do you want to log in or submit with a different address yourself? Go to your profile. Do you want a supplier to submit invoices by email? Set up a trusted sender via the Email Receiver.

Setting up a trusted sender for the first time? Read the step-by-step article in Set up a trusted email sender.

• Set up a trusted email sender
• Add an extra email address to your account
• Submit purchase invoices by email
• Submit sales invoices
• Set up receive notification
• Subscriptions on the eConnect platform
• Set up a workflow