Yes, you can create a separate trusted sender per supplier. Each trusted sender gets a unique email address and its own settings for whitelist type, document type and security options. This gives you full control over who may submit invoices and how they are processed.

The email is rejected and not processed. Only emails from approved senders (based on the configured whitelist type) are accepted. The sender does not receive an error notification — the email is simply not picked up.

Yes, you need at least a Basic subscription to use the Email Receiver. For the "Conversion for multiple organizations" option (administration detection), a Professional subscription or higher is required.

Do you work with multiple entities or a holding structure, and does an Email Receiver at *@trust.econnect.eu stay empty while the sender's domain appears to be whitelisted? First check whether anything actually arrives in the logs or the Inbox of this receiver, not just for another entity. Then open the sent email and look literally at the From field: that is what counts, not the display name. A holding company and a subsidiary often have separate Email Receivers with their own whitelists. The fact that the same outgoing address works for another entity does not prove that the From address and whitelist are correct for this receiver. Check the whitelist entry exactly against the From address: typos, aliases and forwarding rules change the visible sender address. Want to quickly test whether the channel is reachable? Temporarily set the Email Receiver to Accept all (not possible with Draft invoice) and restore the whitelist after the test.

Check this in a fixed order — skipping a step often leads to the wrong conclusion:

1. Correct trust address. Check for typos and the right organization/entity, and whether you used your production or pilot address (trust.econnect.eu versus a pilot variant).
2. Has anything arrived at all? Check whether this Email Receiver received mail in the relevant period. The status Active alone is not enough: an Email Receiver can be active while no email has arrived yet.
3. Whitelist and the From address. If an email was received but is not processed, compare the From address literally with the whitelist setting (see the question above about an empty Email Receiver with multiple entities).
4. Correct organization in the portal. Check whether you are looking at the right organization or administration.
5. Only then check your accounting or ERP connection (for example Metacom): a working connection there does not rule out an empty Inbox or an Email Receiver with no received mail. So start the diagnosis at the Email Receiver's reception, not at the connection.

First check the To/receiving address literally, digit by digit (local part + domain), before diving into the whitelist or the From address. The error message is about the sender/whitelist, but the cause can also be an incorrectly noted receiving address — for example one missing or transposed digit in the local part, copied from a manual, signature or forwarded message. Compare the address used with the Email Receivers actually configured in the platform. That other colleagues within the same organization can successfully submit invoices does not rule out an incorrect To address: check whether the successful and failed attempts were sent to the same receiving address. If the To address is correct and the message persists, only then move on to the whitelist settings (Verified user, domain, specific address) as described above.

This happens with whitelist type Verified user (the default setting). That type only accepts emails whose From address belongs to a user (member) of the organization, or to a verified additional email address on such a user profile. A shared test or accounts-payable mailbox is not a member and therefore does not count, even though it concerns the same Email Receiver address a colleague can successfully submit to.

You have three equivalent solutions, choose what fits best:

1. Create a user for the test address, so it counts as an organization member.
2. Add the address as an additional email address on an existing user profile and verify it via the activation link.
3. Change the whitelist type on the Email Receiver to Specific email address with the test mailbox as the value, or to Entire domain if the whole organization domain may submit.

First confirm the To/receiving address is correct (see the question above) before adjusting the whitelist. A previously rejected email is not automatically reprocessed after the fix: have the sender resubmit the invoice.

A confirmation email when setting up the email connection means at least one email has been successfully received on this Email Receiver — so the connection works. That a PDF invoice you submit afterward is not yet in the draft invoices is usually not an incident but normal processing time: a PDF invoice first goes through IDR conversion (Scan & Recognize) before it appears as a draft invoice. For this conversion: 99% of documents are processed within 8 working hours (see SLA IDR); in practice the average turnaround is lower. Look in the overview under Sales invoice — Draft invoices, not just the generic Inbox. If the invoice remains untraceable even after the waiting period, first check whether the correct receiving address was used and whether the Email Receiver has status Active, before further investigating the whitelist settings.

This occurs when the same supplier normally invoices monthly via *@trust.econnect.eu, but a different invoice type — for example a quarterly or annual statement — does not arrive at that same receiving address. First gather three pieces of information before investigating further: the invoice PDF or invoice number with invoice date, the literal From address of the sender, and the date and (if known) time of sending.

Then follow this order:

1. Receiver hit. Does this Email Receiver show mail or activity around that invoice number or time in the reported period? The status Active alone is not proof of receipt.
2. No hit found. Then the email likely did not reach the Email Receiver. Have someone check whether the To address is exactly correct (typo or missing digit in the local part) and whether the supplier actually sent the invoice. In this case, do not assume a platform outage or whitelist problem without a receiver hit.
3. Hit found, but nothing processed. Compare the From address with the whitelist setting of this receiver and entity, and check whether the invoice ends up in the correct organization or administration.
4. Multiple entities. Do multiple subsidiaries use the same receiver, and does the monthly flow work fine there? That only proves the channel works in general — not that this specific From address, To address or invoice type was correct for this attempt.