← All articles

Automating invoice intake: connecting email, review and filing

A fictional example shows how teams capture PDF invoices, resolve exceptions and file originals with reviewed data.

A shared invoice mailbox brings documents together, but it does not establish who reviews each invoice, which entity it belongs to or where it should be filed. A traceable workflow connects those steps and keeps exceptions visible until an accountable person resolves them.

From intake to reviewed filing

Start with a defined intake, such as an agreed email mailbox and PDF uploads. Specify the fields needed for processing, who checks extracted values and entity assignment, and how incomplete or doubtful documents are routed. The original file should remain accessible alongside its confirmed metadata.

Extraction provides a proposal for review. In particular, check the invoice number, invoice date, supplier, amount and entity against the document and agreed rules. The responsible team determines which fields are required for its particular process.

Fictional example: three invoices for two entities

A finance team processes invoices for two fictional companies, North Ltd and South Ltd. Two PDF invoices arrive by email in a shared mailbox; a third is uploaded as a PDF. The documents and outcomes are invented and do not represent customer results.

  • Invoice A: An email contains a PDF invoice for €1,200. The extracted fields match the original, and the invoice is clearly addressed to North Ltd. The responsible person confirms the fields and checks the proposed export of the original and metadata.
  • Invoice B: Another PDF invoice gives a shared address, so either North or South could be the recipient. The team assigns the question to an accountable person. Filing continues only after the entity is confirmed.
  • Invoice C: The uploaded PDF lacks a field needed for the process. The responsible person follows up with the supplier and, after review, completes or corrects the data. Until then, the case remains open.

A repeated arrival also needs review: is it the same invoice, a correction or a separate transaction? Assign responsibility for that decision and test repeated arrivals in the pilot. Do not assume automatic duplicate handling.

Check filing and handoff

Before handoff, verify that the original, confirmed metadata and destination path match. An existing SharePoint structure, for example by entity, year and month, requires explicit validation of path mapping, naming rules and permissions. Also agree who checks export errors and how corrections are made.

Aivana LISA for invoice intake connects email intake through IMAP or Microsoft Graph and PDF uploads with extraction, entity assignment, review and SharePoint export in its documented product foundation. Export is one-way: manual changes in SharePoint are not automatically synchronized back. Accounting connectors depend on modules and configuration. The actual installation scope, access and licences are checked during the pilot.

Document approval or filing is not proof of payment. The documented banking module does not execute transfers or reconcile transactions. S-Firm handoff and payment feedback are part of a separate extension requiring validation; payment authorisation remains a separate decision.

Keep the pilot manageable

Choose one mailbox, representative PDFs and some deliberately difficult cases. Agree entity rules, review fields, roles and the filing destination. During the pilot, measure processing time, follow-up questions and corrections, and check that documents can be retrieved after handoff. The team can then decide which extension is useful for its own workflow.