# Integrate invoices by email

- 2026-07-10

Configure a verified sender, use the format-specific inbox shown in your profile, and receive proof-backed replies in the original thread; a reply is split into several messages only when its attachments exceed the size limit.

## Account-enabled email channel

Use this channel for controlled, low-volume invoice workflows.

Email invoice conversion is available only to enabled Enterprise accounts in the current pilot. Your account must have an active subscription, email import enabled, and at least one verified sender.

Treat the format-specific inbox addresses displayed in your profile as authoritative. They can differ by environment, so integrations must not hardcode an address copied from examples or internal documentation.

> **Availability**: Enablement and sender verification are completed during onboarding. An ordinary account cannot activate the channel by sending an email.

## Set up the sender before the first invoice

Complete these steps in the account profile before automating a mailbox or ERP rule.

1. Ask the Invoice-Converter team to enable the email channel for the Enterprise account.
2. Add the sending address and finish the verification link sent to that mailbox.
3. Choose whether replies return to the original sender or to a verified collective address, then select the reply language.
4. Copy the XRechnung and ZUGFeRD inbox addresses from the profile and test each required route with one representative PDF.

## Select the target format with the recipient address

| Target | Address to use | Successful reply |
| --- | --- | --- |
| XRechnung | The XRechnung inbox shown in the enabled account profile. | Validated XML plus the artifact-bound HTML validation report. |
| ZUGFeRD / Factur-X | The ZUGFeRD inbox shown in the enabled account profile. | Validated hybrid PDF/A-3 plus the artifact-bound HTML validation report. |

## From intake to reply

Your message is accepted quickly; strict conversion then runs asynchronously and the results arrive as a reply.

1. A verified sender submits genuine PDF attachments to one or more format-specific inboxes.
2. The inbound provider records the message and the service resolves the enabled account, sender, reply destination, and selected target formats.
3. Each accepted PDF becomes a strict conversion task with artifact validation required and no draft or warning override.
4. The requested output is issued only after authoritative validation, persisted proof, and artifact-parity checks pass.
5. Threaded reply messages return issued artifacts and HTML reports; when attachments exceed the per-message size limit, delivery continues in additional messages, while message, item, usage event, proof, and durable reply files remain traceable by ID.

## Billing units and email context

Estimate the units for the whole message before sending, and remember that the email text itself is read as conversion input.

- Each accepted PDF consumes one conversion unit per matched target format. For example, two PDFs sent to both format inboxes require four units.
- Before conversion, the service reserves every unit in the message: first from the included monthly allowance, then from available API credits.
- If coverage is insufficient for all units, the whole message is rejected before conversion. A unit is only charged after its conversion succeeds and the reply artifacts are stored durably; failed units are released.
- If the email contains body text, the verified email subject and body are supplemental conversion input. They can supply missing amendments, corrections, references, or invoice facts. PDF monetary totals, tax totals, and invoice lines take precedence in conflicts, and body text alone cannot create invoice lines. Only a limited amount of body text is read and it may be truncated, so keep signatures and surrounding prose short, relevant, and unambiguous.
- Seller master data stored in your profile completes missing seller fields (name, address, VAT ID, contact) when default use is enabled; it never overwrites values extracted from the PDF.

## Terminal outcomes and artifacts

| Outcome | What the reply says | What is attached |
| --- | --- | --- |
| Issued | The file completed and authoritative validation passed. | The requested primary artifact and its HTML validation report. |
| Partial | At least one file completed and at least one file failed or was skipped. | Only proof-backed artifacts for completed files, plus per-file status in the reply. |
| Validation stopped | Blocking validation details explain why issuance stopped. | No unverified result artifact and no artifact-bound HTML report. |
| Technical rejection | The reply identifies the sender, file, entitlement, limit, or temporary processing problem. | No result artifact; follow the reply guidance before retrying. |

## Accepted files and pilot limits

- Attach genuine PDF files. A renamed image or any other file type is rejected even if its extension or MIME type claims PDF.
- A message can contain multiple PDFs, but the channel is intended for controlled, low-volume workflows rather than bulk ingestion.
- Keep every attachment below the limit communicated during onboarding; provider and environment limits can change.
- If one message reaches more than one recognized format inbox, every accepted PDF is processed once for each selected format.
- Reply attachments are limited to roughly 15 MB per message. When the next file would exceed that limit, the remaining files are sent in another message in the same thread; an individual file is never split.

## What still requires human review

- Compare supplier, buyer, invoice number, dates, currency, tax, totals, payment details, and every line with the source invoice.
- Confirm recipient-specific routing references, endpoint identifiers, purchase-order data, and delivery-channel rules.
- Review low-confidence source evidence and every warning or validation detail before sending the result onward.
- A successful technical validation proves the issued file against the selected rules; it does not replace commercial, tax, or recipient approval.

## Choose email or the API deliberately

| Channel | Best fit | Integration control |
| --- | --- | --- |
| Email channel | Human-operated or mailbox-rule workflows with low volume and a useful reply thread. | Format inbox, verified sender, return address, reply language, and per-message outcomes. |
| External API V1 | Server-to-server workflows that need idempotency, polling, structured status, and explicit download control. | Authenticated requests, client references, correlation IDs, rate-limit headers, and artifact endpoints. |

## Onboarding and support

Share the expected sender addresses, target formats, reply destination, language, and monthly volume during onboarding.

- [Review External API V1 documentation](/developer-api)
- [Request email-channel onboarding](mailto:contact@invoice-converter.com?subject=Email%20invoice%20channel%20onboarding)