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.

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 sender settings include a fallback email address. Notifications go to this address if no other recipient is configured. Are notifications suddenly going to a different address (or not arriving at all)? Check this field.

Alternative: the Use sender email address as contact email address checkbox. When enabled, notifications are sent to the email address that submitted the invoice (the sender). This was the default behaviour for many receivers before an update.

To change:

1. Open the Email Receiver of the relevant organisation (Apps > Email Receiver).
2. Adjust the fallback email address, or enable the checkbox above.
3. You can do this yourself; support can assist on request.

Scope with multiple organisations: the Email Receiver is per organisation. A change does not automatically apply to all companies in a group. Using the same address on multiple organisations? Check and set it per organisation/receiver separately.

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.
• Enabling the option on the email receiver sends the configuration to the IDR. This creates an IDR group (administration group) containing the organisations from the account. That group determines which organisations the IDR may choose from; assignment outside the account is not possible.

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 additionally receives the data of the other administrations in the same account or environment. That group determines which organisations the IDR may choose from. 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 parts: first the IDR (sets the recognised organisation in the XML), then the platform (places the XML at the correct platform organisation).

IDR phase

1. Identifiers (highest priority): exact match on identifiers in the PDF document (including VAT number, chamber-of-commerce number) against organisations in the IDR group. On an exact match that organisation is chosen; other candidates are dropped.
2. Soft matching: no identifier match -> organisation name in the document, plus city and postcode. Exactly one match -> automatic selection. Multiple matches -> Quality Control (manual choice within the account).

Platform phase

• Routing on the field Invoice/AccountingCustomerParty/Party/PartyLegalEntity/CompanyID against party IDs in the platform.
• Match -> invoice is placed at that organisation.
• No match -> default = owner of the email receiver.
• The platform enriches or corrects the XML with organisation data from the platform (the platform is authoritative): including VAT number and organisation name from the platform.

Only organisations that are part of the same environment or account are eligible. Recognition can happen automatically by the robot or manually by Quality Control. 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.

Is an invoice placed at the wrong organisation in your account, while the VAT number or chamber-of-commerce number on the document are correct? Also check the PartyLegalEntity/CompanyID field and the organisation name on the document: the platform phase routes on CompanyID, so a differing name or CompanyID can still lead to the wrong (sister) organisation, even when the VAT number is correct.

Is this a one-off discrepancy (for example an unusual PDF layout)? Report it to support as feedback on the conversion. Does the same problem occur structurally with similar documents or name variants of sister organisations? Then eConnect can set up an alias or hint to improve recognition; contact support for this.

Known multiparty scenario with German organisations:

• 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.

When a supplier attaches both an XML and a PDF file 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 message. The PDF attachment in the same email is still processed normally.

This error message cannot be suppressed while the PDF is being processed: the XML is offered for validation and fails. If a supplier structurally sends both XML and PDF but only the PDF is desired, support can set the email receiver to digital invoices only (PDF). The XML attachment is then no longer offered for validation and the error message 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.

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 the Office 365 connection (PSB reads the mailbox via Graph/OAuth).

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.

If your organisation does use forwarding, you can forward invoice mail from your own addresses (for example invoices@customer.nl) to the Email Receiver without giving end users additional mailbox rights. This is customer-side forwarding to an eConnect receiving address -- not the same route as the Office 365 connection above.

Pattern: mail contact + distribution group (preserves the original sender):

1. Create an Email Receiver address in the platform and set the status to Active.
2. In the Exchange Admin Center, create a mail contact whose external address is the platform's Email Receiver address.
3. Create a distribution group with the customer-facing invoice address (the address suppliers use). Member = the mail contact from step 2. Optional: an extra alias on the same group.
4. Test with an invoice from an allowed sender address and check receipt in the platform.

Whitelist: with a single generic invoice address for all suppliers, the Email Receiver is often set to Accept all, so that all suppliers can submit. Accept all is not allowed with document type Draft invoice. Safer: a dedicated Email Receiver address plus its own contact address per supplier (useful for no-reply senders).

Blockers and alternative:

• Exchange/O365 blocks external forwarding ("Your organization does not allow external forwarding") -> IT adjusts the forwarding policy, or choose the Office 365 connection (reading the mailbox instead of forwarding).
• Forwarding loop (eConnect mail is also forwarded back) -> filter: do not forward mail from the domains everbinding.nl or econnect.eu.

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 (or domains) 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 (or their corresponding domains) 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.

More background on Microsoft's per-recipient rate limits: Message rate limits (Microsoft Learn).

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.