INVOICE, ORDER, CUSTOM, or NONE.
Invoice template
Refunds and credit notes
When the email is about a refund, credit note, or refund receipt,document_type is credit_note and the fields describe the refund: invoice_number is the refund/credit number, invoice_date the refund date, line_items only the refunded items, and description what was refunded. Amounts stay positive — document_type carries the sign, so subtract credit notes in your bookkeeping. If the same email also attaches the original invoice, BounceBox extracts the refund, not the original invoice, and puts the original number in credited_invoice_number.
Order template
Each order line item:
SKU matching is available for order templates on every plan, including Starter. Active catalog products provide matching context; a result may remain unmatched or require correction. Check matches against the source before approving delivery. See SKU Catalog and Inbox.
Matching and review. Ordered units are compared to the catalog
uom case-insensitively, with tolerance for plurals, translations, and standard abbreviations in any language (tubs matches tub, Dosen matches tin, Stk matches Stück); genuinely different units or pack sizes block delivery until corrected in review. Customer accounts (sender addresses, per-customer codes remembered at approval, optional order history) let repeat customers match by their own part numbers; “same as last week” reorders are pre-filled from the customer’s latest approved order and held for confirmation. Forwarded orders are extracted normally but never inherit customer memory — assign the customer in review if needed.
Custom template
Available on Pro and Custom plans. Select theCUSTOM template chip, then build the schema in the field builder: each row is a field with a name, a type (TEXT, NUMBER, or DATE), and a description. Suggestion chips (customer_name, request_summary, amount, due_date) add common fields in one tap; Add field appends a blank row. A custom schema needs at least one uniquely named field.
The description is what the model reads, so write it like an instruction — say what the field is, where it lives in the document, and what to do when it’s missing. Dates are extracted as text; put the expected format in the description.
Junk/newsletter triage still applies to custom mailboxes, but it judges against the mailbox’s extraction purpose rather than orders and invoices. The mailbox’s Instructions for the model define what counts as relevant content, so describe the content you expect (e.g. “sales inquiries”, “support tickets”), not only field rules.
None — store only
NONE disables extraction entirely. Mail still lands in the inbox with its subject, sender, and attachments, but it is never sent through AI extraction — it shows as SKIPPED and no extracted result, reply, or webhook delivery is produced. The sender allowlist still applies: mail from senders not on it is stored but immediately marked SKIPPED (sender_not_allowed), so the allowlist screens it out before any processing.
Use it for mailboxes that are just a drop point — a forwarding archive, a holding address for mail you’ll sort later, or anywhere you want the raw mail without structured data. Switching the template back to invoice, order, or custom at any time restores extraction for new mail, and you can reprocess an older email from its inbox page to extract it retroactively.
Instructions for the model
Every template ships with sensible default extraction instructions. For mailbox-specific rules, use Instructions for the model in the mailbox editor — up to 4000 characters of free text. Good uses:- “All dates in these invoices are DD/MM/YYYY.”
- “Ignore footer totals; the real total is in the summary table.”
- “Tax is always 21% VAT unless the document states otherwise.”