Sending documents in

DocReadi accepts documents through five different doors: a manual upload, email, WhatsApp, a watched folder, or the REST API. Pick whichever matches how a given supplier or process actually sends you paperwork — you don't have to standardise on one.

What DocReadi accepts

Every ingestion route — upload, email, WhatsApp, Inbox, and the API — takes PDF, JPG, and PNG. A single PDF can span multiple pages; very large PDFs are capped (the default limit is 500 pages) so one oversized batch file can't stall your pipeline. If a document arrives as an unsupported file type, it's rejected rather than silently dropped, so the source that sent it knows.

Statements of account can be sent in through any of these routes alongside the invoices they cover. A statement is recognised as a statement, so the invoices its rows refer to aren't recorded a second time — see Statements of account. If a particular route only ever carries statements, pick Vendor Statement or Customer Statement as the document type — on the upload panel's Document type selector, or in an Inbox source's Document type (skip auto-classify) setting — instead of leaving it on auto-detect.

E-invoice XML

DocReadi also reads structured e-invoice XML sent as a plain .xml file. Two families are supported:

UBL 2.1 — an Invoice or CreditNote document. Peppol BIS and XRechnung files are this format.
UN/CEFACT CII — a CrossIndustryInvoice document. This is the ZUGFeRD / Factur-X schema, sent on its own rather than embedded inside a PDF.

FatturaPA is not supported. Neither is any supplier's in-house XML dialect — if it isn't one of the two above, it's rejected with a reason (see An e-invoice XML DocReadi couldn't read).

XML goes in through the web upload panel, the REST API, watched Inbox folders, and email — attach the .xml file to a message to your inbox address like any other document. The one route that doesn't take it is WhatsApp, which handles PDFs and photos only; send an .xml file to that number and the sender gets a reply asking for a PDF or a photo instead.

Three things worth knowing before you send one:

The Upload Documents panel takes XML like any other file — click to browse or drag it in. The panel lists what it accepts: PDF, JPG, PNG, e-invoice XML.
An Inbox source only picks up the extensions listed in its File extensions filter. A source you create now has xml in that list by default; a source created earlier keeps the filter it was saved with, so add xml to it yourself under Sync → Inbox.
Don't pick one of your custom templates when you send an XML file. DocReadi maps e-invoice XML onto the built-in invoice types, and a template selection stops the document with a Failed status.

An e-invoice XML is read straight out of the file rather than by a model, so it consumes no credits and always waits for you in the review queue — see E-invoice XML.

Web upload

The simplest path: drag a file onto the Upload Documents panel on your dashboard (/ui), or tap to browse on mobile. This is covered in Getting started.

Email-in

Every workspace gets a dedicated inbox address of the form <your-slug>[email protected], set up automatically at signup — there's nothing to configure to start using it. Forward supplier invoices to that address (or ask suppliers to CC it directly) and each attachment arrives as a new document, the same as an upload.

To connect a different email address with its own rules — a specific local-part, or a sender allowlist so only mail from approved addresses is accepted — go to Sync → Connections, add a connection of kind Email — receive documents at an inbox address (forward your invoices in), then add an Inbox source against it under Sync → Inbox (the Sync menu in the top navigation bar). Sources built on an email connection take a local-part and an optional sender allowlist instead of a folder path.

Email log — what happened to a message

Sync → Email log (or the Email log tab under Sync → Inbox) lists every message that reached one of your workspace's inbox addresses — accepted as well as rejected — newest first, up to the 500 most recent. A message with more than one attachment gets one row per attachment. Unlike the rest of the Sync cluster, this page is visible to the Reviewer role as well as Admin and Firm admin, since "did that invoice arrive?" is a day-to-day reviewer question.

Each row shows who it came from and which of your addresses it was sent to, the subject, when it arrived, the attachment (filename and file type, or "no attachment"), and an outcome:

Processed — a document was created; the row links straight to it.
Already had it — the same attachment arrived again (a mail server retry) and was skipped — not an error.
Nothing to process — the message carried nothing DocReadi could use: an attached file type it can't read (only PDF, JPG, PNG and e-invoice XML are supported), no attachment at all, or a message DocReadi couldn't parse at all (the sender gets a bounce). This includes an invoice pasted directly into the message body — that doesn't count as an attachment; the file needs to be attached.
Not accepted — the message was refused outright: the sender isn't on the inbox source's sender allowlist, or the attached PDF is over the page limit (split it and resend — see What DocReadi accepts).
Failed — the attachment was accepted and a document exists, but processing hit an error afterwards.

A short explanation appears under any row that isn't Processed or Already had it. Use Only problems to filter the list down to everything that didn't leave you a document. Entries are kept for 90 days; DocReadi records the sender address and subject but never stores the message body.

If your workspace has a Meta WhatsApp Business number connected, anyone who messages that number with a document attached gets it ingested automatically. Set this up under Sync → Connections with a connection of kind WhatsApp — receive documents on a Meta WhatsApp Business number, using the Phone Number ID and WhatsApp Business Account ID from Meta's API Setup page. Once connected, a sender can optionally be shown a tap-to-pick document type menu instead of relying on classification — control this per number under Settings → WhatsApp senders, which lists every phone number that has sent a document and lets you set its default document type and template. The menu starts with Auto detect, then Receipt, AP Invoice, Sales Invoice and Delivery Note, so the usual choices are on the first screen; tap More… for the other document types and your custom templates.

The sender gets a reply back that reflects what actually happened: a short summary once a document is read, a note that it's taking longer than usual if processing is still running, or — if your workspace is out of credits — that the document is waiting on a top-up, with a link to add credits. On a trial workspace whose admin hasn't verified their email yet, the reply instead says the document is saved but waiting for verification — it resumes on its own once the admin verifies (see Verifying your email). A document is never reported as processed when it wasn't.

WhatsApp takes PDFs and photos — PDF, JPG, and PNG. Anything else is turned away as it arrives: the sender gets a reply saying DocReadi can't read that file type and asking them to send a PDF or a photo of the document. Nothing is stored, nothing appears in your Documents list or review queue, and no credit is spent. A file DocReadi can't open at all — password-protected, or saved in an older format — gets its own reply, which asks the sender to save a current version or send a PDF instead. DocReadi decides from the file itself rather than from the label the sending app puts on it, so a mislabelled file is turned away too. Ask the sender to resend as a PDF or a photo and it goes through normally.

Inbox — watched folders

For suppliers or systems that drop files into a folder rather than emailing them, Sync → Inbox (the Sync menu in the top navigation bar) watches a folder on a schedule and pulls in whatever it finds. A watched folder can live on SFTP, S3 (including S3-compatible services such as Cloudflare R2, Backblaze B2, or MinIO), OneDrive, or a SharePoint document library.

Setting one up is two steps:

Add a connection under Sync → Connections. For SFTP or S3, this is a credential set (host, port, username, key or password for SFTP; bucket, region, and access keys for S3). For OneDrive or SharePoint, select the matching Connect… button instead and sign in through the provider's own consent screen — see Delivering documents → Connections for what each cloud-drive connection asks for, including the SharePoint site + document-library picker. A connection can be shared by more than one Inbox source or Outbox destination.
Add an Inbox source under Sync → Inbox, pointing at that connection: a folder path, optional file extension/glob filters (File extensions defaults to pdf, jpg, jpeg, png, xml), a max file size, how often to poll, and what happens after pickup — leave the file in place, move it to an archive subfolder, or delete it. For OneDrive and SharePoint you can type a folder path or use Browse…. Moving or deleting after pickup needs the read-write access the cloud-drive connection already requested — a source left on leave only ever reads.

A newly-created source (SFTP, S3, OneDrive, or SharePoint) is picked up on the next poll sweep, within about 30 seconds, instead of waiting out its configured poll interval — you don't need to click Fetch to see the first result. Saving changes to an existing source does the same: editing a source resets it to due-now, so a corrected path or credential is re-tried within about 30 seconds rather than sitting idle for the rest of the poll interval. This applies to pull-based sources only — email and WhatsApp sources aren't polled, so there's nothing to re-trigger on save.

Each source's dashboard row shows its last poll status and how many documents it has pulled in today and over the last 7 days, so you can see at a glance whether a source is actually working. If a poll fails repeatedly, check Sync → Inbox → Failures for the reason and a retry button.

A newly-arrived file, or one that's still being uploaded, is left alone for one poll cycle and only picked up once its size and modified time are unchanged across two consecutive polls — so a file that's still mid-upload is never ingested truncated. This adds roughly one poll interval of extra latency before a brand-new file appears, which is expected.

Quarantine — files DocReadi couldn't pick up cleanly

Sync → Inbox → Failures lists files DocReadi noticed but didn't ingest, each with a reason. For mail specifically, the Email log is the more complete picture — it also shows messages that never reached this page at all, including ones with no usable attachment.

Oversize — the file is bigger than the source's configured max file size. Raise the size cap in the source's file filter and it will ingest on the next poll.
Zero Byte — the file is empty (0 bytes), usually an upload that never finished.
Other reasons cover things like a corrupt or password-protected file, or an unsupported format.

Each row has a Retry button that re-fetches the file from the source and tries again. Retry works for SFTP, S3, OneDrive, and SharePoint sources. For email and WhatsApp sources, Retry is greyed out — there's no remote copy to re-download for those — use Resolve instead to mark the row handled once you've dealt with it another way.

API and automated integrations

For programmatic ingest — a script, an accounting-system integration, or an agent — DocReadi exposes a REST API. The full reference, including every endpoint, request/response shape, and authentication details, lives at /api/docs-guide; this guide won't duplicate it.

You'll need an API key to call it. Mint one under Settings → API keys (requires your email to be verified first — see Getting started). A key's plaintext value is shown exactly once, at creation — DocReadi stores only a hash, so if you lose it you'll need to create a new one and revoke the old. You can give a key an expiry when you create it (30 days, 90 days, or a year; the default is no expiry). An expired key stops authenticating immediately — the list marks it Expired — and can't be renewed: create a fresh key and revoke the old one. Existing keys can be revoked or deleted from the same page at any time.

Each key also has an access level, chosen when you create it. An Admin key can ingest, extract and manage integrations. A Reviewer key can read and review documents and run reports, and it sees bank numbers the way a Reviewer does in the app: a bank account number or IBAN comes back as ••••7890, the last four only, in document data, extraction results, the document's parsed text, confirmed review answers and saved reports. An admin can grant one Reviewer key full numbers under Bank number access; the key then shows a Full bank numbers badge on this page. Otherwise use an Admin key for an integration that needs the full number. Every API response that applies the bank-number rule includes an X-Bank-Numbers header, full or masked. Webhooks and outbox deliveries, which an Admin sets up, always carry the full number.

A single call to POST /extract with your API key and a document attached is the fastest way to test the pipeline programmatically — parse the response and you have the same structured record a document gets once it clears your review queue. It uses credits the way an upload does: the document's pages once, then one free re-extract. Because it extracts from the text you send, a very long text costs more than its page count, charged by length (/api/docs-guide gives the exact rate). Nothing is refused for length. If your workspace's balance doesn't cover the call, the call is refused (HTTP 402) and nothing is charged. /api/docs-guide covers this endpoint alongside every other one, including how to check a document's status, list and search your documents, and pull reports.

Keeping track of what arrived

Whichever door a document comes through, it's stamped with where it came from — a web upload, a specific email address, a WhatsApp number, a named Inbox source, or the API — so you can always trace a document back to its origin. The Inbox dashboard (Sync → Inbox) is the place to check whether an automated source is actually pulling documents in: each source shows its last poll status and how many documents it's picked up recently. If nothing is arriving from a source you expect to be active, that's the first place to look before contacting support. For "did this specific invoice arrive by email?", check the Email log instead — it records every message, not just the ones that became documents.

What happens next

However a document arrives, it lands in the same place: your document pipeline. See How processing works for what happens between arrival and your review queue.

Looking for the developer/API reference? See /api/docs-guide. Can't find an answer? Email [email protected].