The Email Receiver (also called Trusted Sender) is an App in the eConnect platform that lets you receive and process invoices by email, part of Scan & Recognise. You set a trusted email address or domain, and invoices sent from that address are processed automatically.

Note: the Email Receiver is an App (under Apps in the platform menu), not a connection. If you want received invoices forwarded automatically to an email address, use the Email connector. That belongs under Connections. See Connection keys: Email connector, forward received invoices.

Many software packages use the Email Receiver as their primary connection method with eConnect. The platform generates a unique email address per organisation. Your software sends invoices as an attachment to that address and the platform processes them further, depending on the configured document type.

When you create an Email Receiver, the platform generates a unique email address. You pass this address to your software vendor or enter it in your package. As soon as your software sends an invoice as an attachment to that address, the platform processes the invoice automatically. XML invoices are processed directly. PDF invoices are converted to e-invoice format (UBL) via IDR conversion.

Which processing takes place depends on the document type you configured: draft invoice, sales invoice or purchase invoice.

An incoming supplier email first reaches the Email Receiver. Classification, the trusted-sender check and the document-type assignment happen there. The flow then splits: invoice to processing, attach a specification, or ignore a logo and terms. Each supplier gets a unique address on trust.econnect.eu.

When you create an Email Receiver, you choose a document type. This determines how the received invoice is processed.

The invoice is prepared as a draft on the platform. You can review the invoice and then send it manually to the recipient via Peppol. If you enable XML auto-send, valid XML invoices are sent automatically without manual intervention.

The invoice goes straight to the archive for administrative processing. This suits situations where the invoice is already final and needs no further check before it is archived.

The invoice is delivered to the recipient as a purchase invoice. If the invoice is already supplied as UBL, conversion is skipped. For a PDF invoice, IDR conversion to e-invoice format takes place.

Navigation for new customers: after registration you land on the environment/account management view. The Email Receiver is not visible there directly. In the menu, click Apps → Email receiver (Email Receiver) to open the overview. Under All you see the automatically created receiver email address of your organisation.

1. Log in to platform.econnect.eu.
2. Go to the Email Receiver app (under Apps in the left menu).
3. Click New sender (the orange button with the plus icon).
4. Set the following fields:
   • Organisation: select the organisation for which you want to process invoices.
   • Invoice type: choose Draft invoice, Sales invoice or Purchase invoice.
   • Whitelist type: enter the email address or domain of the sender that may submit. One domain or email address can be whitelisted per Email Receiver.
   • Contact email address: the address where rejection notices are sent.
5. Click Save. The platform generates a unique email address for this connection.
6. Activate the trusted sender. You can do this in two ways: change the status manually to "Active", or send an invitation to the sender. With an invitation, the sender receives an email explaining the generated address. On first use, the Email Receiver is activated automatically.
7. Pass the generated email address to your software vendor or enter it in your package.

Does an organisation need to receive invoices from several domains? Create a separate Email Receiver address for each domain.

• Notification on receipt: you receive an email when an invoice has been submitted and processed.
• SSL/TLS requirement: only process emails sent over a secured connection.
• XML auto-send: valid XML invoices are sent automatically without manual review. Requires SSL/TLS to be enabled and the XML to be valid.
• Allowed document types: choose whether you accept only e-invoices (XML), only digital invoices (PDF), or both.
• Supplier recognition: set which email field is used to recognise the supplier. The default is the sender address, but for aliases or forwarding setups you can choose another field (for example Reply-To). The recognised address is also included in the XML delivered to your accounting system.
• Conversion for multiple organisations (Conversion for multiple organizations): administration detection / multiparty conversion. The IDR automatically determines which administration within the same account a PDF invoice is intended for, even if it was submitted via another organisation's email receiver. Requires at least Professional (named separately in the contract), feature-pack option Allow multi party for IDR conversion (IDR Features tab), and the option on the email receiver. Enabling it creates an IDR group (administration group) with the organisations from the account. The default is the email-receiver organisation. On a better match, the system places the invoice on the other administration. When in doubt, the default remains. The platform phase routes on Invoice/AccountingCustomerParty/Party/PartyLegalEntity/CompanyID and is leading for XML enrichment (including VAT number and organisation name). A dummy Leitweg-ID in CompanyID (Germany) can make the match fail, so the default organisation is used. Details: Email receiver.

Note: a final invoice from your software must not be changed in debtor and invoice lines after it arrives as a draft invoice on the eConnect platform. Only check the invoice for correctness, then send it.

A defective or inactive Email Receiver does not have to be repaired by creating a new Email Receiver. Often the Trusted Sender is not yet active or is configured incorrectly. When "email not received", check these points first:

1. Email address copied correctly. Check for typos in the generated …@trust.econnect.eu address you passed to the software package.
2. Email Receiver status Active. If the Trusted Sender is still on status "Created draft", the Email Receiver is not yet active and cannot be used. The sender then receives a bounce (unless another active Email Receiver with a different contact email address is configured).
3. Correct whitelist. Check that the sender's email address or domain is set correctly in the Email Receiver whitelist.
4. Correct document type selected. With the wrong document type, invoices are processed incorrectly. Example: a Trusted Sender created with document type Purchase invoice processes invoices as a purchase invoice instead of a draft invoice. Creating a new Email Receiver with document type Draft invoice may have been chosen as a temporary workaround, but preferably correct the document type on the existing Email Receiver.

Is the invoice visible on the platform after receipt via the Email Receiver, but not (yet) in UBW/Agresso, Unit4 or another connected package? First distinguish a temporary batch or forwarding delay from a persistently missing forward: see ERP troubleshooting: invoice on the platform, not yet in UBW.

When invoices are sent by email to recipients that are not in Peppol, the customer account setting determines which documents are included in the email fallback. Do you want documents included in the email fallback? Contact us for the options and any costs.

Recommended alternatives for recipients outside Peppol:

• Peppol registration of the recipient: the most robust route. Invoices then go via Peppol instead of by email.
• Account on the platform: the recipient creates an account and uses an Email connector (Connections) to forward received invoices automatically. See Connection keys: Email connector.

On rejection, the Email Receiver sends an error message to the contact email address of that receiver. That field is not the fallback email address. Where receiver notifications go, and how you change the fallback email address yourself: see Fallback email address.

Invalid or unrecognised XML is rejected and does not appear as a processed invoice in the platform. A whitelist block is a separate path (sender not allowed). A sender on the whitelist does not rule out an XML rejection.

• No processable attachments: no invoice files recognised in the email.
• Whitelist block: the sender is not on the whitelist. No file is processed.
• SSL/TLS error: the email was not sent over a secured connection and is not processed.
• Invalid or unrecognised XML: error message with instructions on UBL validity and UTF-8 encoding. If the email also contains a PDF next to the XML, the PDF is still processed. The notice for the rejected XML cannot be suppressed in that case as long as the PDF is processed.
• UBL validation error on the XML attachment (for example BR-CO-18 / BR-Z-01 / BR-Z-05 Zero rated / zero rate): the rejection concerns only the attached XML. If the same email also contains a PDF, that PDF is processed normally while the rejected XML generates the error message ("Processing is not possible" / "We could not process the UBL invoice in the attachment").

Tip for structural XML and PDF submission: if a supplier always submits both XML and PDF but only the PDF is wanted, there are two routes: (1) the supplier fixes the XML or omits the XML attachment (drop the XML); (2) support can set the Email Receiver to digital invoices (PDF) only. With route 2, the XML is no longer offered for validation and the related error message disappears. This is a configuration change by support, at the customer's request.

The Email Receiver classifies the attachments in an incoming email and decides which document is the invoice and which is an attachment. eConnect checks each submitted document separately for attachment/invoice status. Documents are merged in submission order: the first document becomes the first page of the invoice, even if it is an attachment. Once a file is recognised as an attachment, all following files in the same email are also treated as attachments.

When several PDF files are submitted:

• One file recognised as an invoice, the others are other document types. The other documents in the same email are treated as attachments and added to the invoice by default. Think of a damage note, packing slip or specification next to the real invoice PDF: you may call both documents "invoice", but if Detect does not recognise one as an invoice, that is not a split error but expected behaviour. The non-invoice document becomes an attachment to the recognised invoice. Unsure whether the second document is still an invoice (invoice number, VAT, amount payable, supplier/recipient present)? Request the original PDF attachments and the XML from Inbox for investigation.
• Several attachments recognised as an invoice. Each invoice PDF is processed individually (separate invoices). The system does not automatically link other attachments to a specific invoice in the same email. If in doubt, send 1 invoice per email.

Merge logic with and without XML in the email: if the email contains no XML, the logic above applies based on Detect classification (one declaration or invoice, attachments are added; two or more declarations or invoices, everything is processed separately). If the email does contain a valid XML invoice, a different rule applies: a PDF with exactly the same file name as the XML is added to that XML. Other attachments are classified via Detect and may be processed separately. With two or more valid XMLs in the same email, an attachment with exactly the same name is added to the matching XML. The other files are processed separately.

If Detect wrongly recognises a standalone overview or specification PDF as an invoice, an extra invoice appears next to the real invoice. See Multiple PDF attachments in one email to prevent this.

Excel/ODS/CSV attachment next to a PDF invoice: an Excel attachment does not block processing of the PDF invoice, provided the file is in a supported format and not larger than 5 MB. Behaviour per scenario:

• Supported format and not larger than 5 MB (.xlsx, .ods, .csv): the file is added to the invoice as a secondary attachment (not sent to IDR). The PDF invoice is processed normally.
• Supported format and 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).

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

Large attachments: a very large attachment is reduced so the PDF stays manageable.

Merge attachments: the platform can merge all attachments in an e-invoice into one PDF.

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

Submitted PDF unchanged: eConnect only handles translation/processing and does not change the submitted PDF file itself (a PDF can still be generated).

Does a sender get a bounce or notification that a document is "an attachment or specification", while the related invoice from the same email was processed normally? The same notice also appears as "Document type is incorrect" or "The submitted file (Purchase invoice) cannot be handled because the document type is incorrect". The English subject line of the same notice is "This is an attachment/specification". The bounce can also apply to an inline image (image012.png) or to an invoice overview in a forwarded email. That is not a contradiction. They are two separate outcomes within one email.

1. The notice is separate from the invoice status. The notice says nothing about whether the invoice itself failed. Check the invoice status separately in Inbox.
2. False-positive start of a conversion task. A PDF or image with enough invoice signal (for example the word "Invoice" with a number) starts its own conversion task. If that document is not an invoice, the bounce on that document is correct, separate from the real invoice in the same email.
3. No late re-linking. Once a conversion task has started for an attachment, that attachment is not linked to the invoice afterwards.
4. Separate conversion tasks cannot be merged. Several files that initially started as an invoice remain separate conversion tasks. They cannot be merged afterwards.

Product roadmap: a structural improvement of classification "at the front door" is planned in a future PSB version of the Email Receiver (horizon about 12 months from September 2026). Until then, the behaviour above applies.

Customers with Microsoft 365 / Exchange can forward invoice mail from their own addresses (for example invoices@customer.com) to the Email Receiver without giving end users extra mailbox rights. This is customer-side forwarding to an eConnect receiving address. This is not the Office 365 connection in which PSB reads the mailbox via Graph/OAuth.

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

1. Create an Email Receiver address on the platform and set the status to Active.
2. In Exchange Admin Center, create a mail contact whose external address is the platform Email Receiver address.
3. Create a distribution group with the customer-facing invoice address. Member = the mail contact. Optional: an extra alias on the same group.
4. Test receipt on the platform.

With one generic invoice address, the receiver is often set to whitelist Accept all (not with Draft invoice). If Exchange blocks external forwarding, choose the Office 365 mailbox connection. Prevent forwarding loops: do not forward mail from the domains everbinding.nl or econnect.eu.

See also Email receiver for the platform UI route.

Want to know which integration methods exist for your software? View the integration methods overview.