email inbox ingestion for invoices: dedup and attachments
Builds email inbox ingestion for invoices with dedup and attachment handling. Use for AP email intake. Not for portal or EDI intake.
TL;DR
Email is the messiest intake channel: forwards, duplicates, zipped attachments, and non-invoice content. Ingest by extracting attachments (including from zips), deduping on content hash plus sender, classifying invoice vs non-invoice, and threading replies to the original invoice. Treat the inbox as untrusted input, not a clean feed.
Steps
- Extract attachments, recursing into zips.
Expected: All candidate documents.
- Dedupe on content hash and sender.
Expected: No double intake.
- Classify invoice vs statement vs correspondence.
Expected: Right handling per type.
- Thread replies to existing invoices.
Expected: Context preserved.
- Quarantine suspicious attachments.
Expected: Security.
When to use
- Email AP intake
- Dedup design
- Multi-channel intake
When not to use
- Portal intake
- EDI intake
- Invoice processing itself
Compatibility
Email APIs (Gmail, Outlook); ERP-agnostic downstream.
Variant phrasings
AP email ingestion
invoice inbox automation
email attachment dedup invoices
Root cause
The same invoice arrives by email multiple times through forwards and CCs. Without content-hash dedup, each copy becomes a payable.
Edge cases
- Password-protected zips need a sender protocol
- Embedded images in the email body can be invoices too
- Phishing via invoice email is common; verify senders
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ci9v1qagsoAlXbdL1beKRQ
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.