Receipt Finder & Organizer

=== RECEIPT FINDER & ORGANIZER ARCHITECTURE ===

Business
Northstar Creative Studio

Processing Mode
Hybrid

Primary Mailbox
Authorized company Gmail inbox

Finance Destination
finance@northstar-example.com

Storage Root
Finance Records

=== EXECUTIVE SUMMARY ===

The workflow will search new email daily and perform a controlled historical backfill beginning January 1, 2026.

High-confidence business receipts will be

1. Qualified as a supported expense document.
2. Classified as business-related.
3. Checked for duplicates.
4. Assigned to the correct transaction month.
5. Renamed using the approved naming pattern.
6. Stored in the correct monthly folder.
7. Forwarded once to finance.
8. Written to the processing log.

Ambiguous, personal, unreadable, duplicated, password-protected, incomplete, refunded, or conflicting documents will enter the review queue.

Source messages and original attachments will not be deleted.

=== SEARCH STRATEGY ===

Search Signals

Document Keywords

• receipt
• invoice
• tax invoice
• payment confirmation
• paid
• order confirmation
• subscription
• renewal
• refund
• credit note
• billing statement

Attachment Signals

• PDF
• image receipt
• document attachment
• structured HTML receipt

Sender Signals

• approved vendor domains
• billing aliases
• payment processors
• subscription services

Content Signals

• amount
• currency
• invoice number
• order number
• transaction date
• payment method reference
• company billing name
• company billing address

Exclusions

• newsletters
• promotional offers
• abandoned-cart messages
• shipping-only updates
• product announcements
• password-reset messages
• unrelated account alerts
• personal purchases
• messages already marked as successfully processed

=== RECEIPT QUALIFICATION ===

High Confidence

A document is high confidence when

• the sender is an approved vendor or verified billing domain
• a receipt or invoice document is present
• an amount and currency are visible
• a transaction or invoice date is visible
• the company identity or approved payment method is present
• the message represents a completed charge, invoice, refund, or credit
• no strong personal-use signal is present

Medium Confidence

• probable receipt
• amount is visible
• vendor is identifiable
• business purpose is plausible
• one important field is missing or unclear

Action
Queue for review.

Low Confidence

• marketing message
• incomplete order
• no completed-payment evidence
• personal purchase signal
• unrelated attachment
• unsupported file
• unreadable document

Action
Skip or queue according to risk.

=== BUSINESS-PURPOSE CLASSIFICATION ===

Business Confirmed
Approved vendor, company billing identity, approved company card, business email, project reference, or approved expense category.

Personal
Personal billing identity, personal shipping purpose, household purchase, or user-defined personal vendor.

Ambiguous
Insufficient evidence to distinguish business from personal.

Rule
Ambiguous documents are never forwarded automatically.

=== DOCUMENT TYPES ===

Receipt
Evidence of completed payment.

Invoice
Request for payment or formal billing document.

Payment Confirmation
Evidence that a payment was processed.

Subscription Charge
Recurring service charge.

Refund
Money returned for an earlier expense.

Credit Note
Formal reduction or reversal.

Cancellation
Document indicating that a transaction or service was cancelled.

Exception
Document requiring manual interpretation.

=== DATE POLICY ===

Primary
Transaction date

Secondary
Invoice issue date

Fallback
Email received date

Fallback Status
Requires Date Verification

Late Arrival
A document received after its transaction month is filed in the transaction month and marked Late Arrival.

=== MONTHLY FOLDER STRUCTURE ===

Finance Records
└── 2026
└── 07 - July
├── Receipts
├── Invoices
├── Refunds and Credits
├── Exceptions
└── Processing Log

Folder Rules

• Create the year folder when absent.
• Create the month folder when absent.
• Do not create repeated month folders with alternate names.
• Store refunds and credit notes separately.
• Store unresolved documents in Exceptions.
• Preserve a processing log for every month.

=== FILE-NAMING STANDARD ===

Format

YYYY-MM-DD - Vendor - Amount Currency - Document Type - Reference.ext

Example

2026-07-14 - Adobe - 59.99 USD - Invoice - INV-84721.pdf

Fallback Without Reference

2026-07-14 - Adobe - 59.99 USD - Invoice.pdf

Fallback Without Verified Amount

2026-07-14 - Adobe - Amount Unverified - Invoice - INV-84721.pdf

Rules

• Sanitize unsafe characters.
• Preserve the original extension.
• Do not overwrite an existing unrelated file.
• Use a duplicate-safe suffix only after duplicate analysis.
• Keep names understandable outside the email system.

=== FORWARDING SPECIFICATION ===

Recipient
finance@northstar-example.com

Subject

Receipt | 2026-07 | Adobe | 59.99 USD | INV-84721

Body

Vendor
Adobe

Transaction Date
July 14, 2026

Amount
59.99 USD

Document Type
Invoice

Expense Category
Software

Storage Destination
Finance Records/2026/07 - July/Invoices

Business-Purpose Confidence
High

Source
Original company mailbox message

Attachments
Original verified invoice

Rules

• Forward once.
• Include only relevant context.
• Do not forward unrelated thread content.
• Preserve the original document.
• Record the resulting forward status.
• Do not repeat the forward when a later storage or logging action fails.

=== DUPLICATE CONTROL ===

Primary Identifiers

• source message ID
• attachment hash where supported
• invoice number
• order number
• transaction number

Secondary Comparison

• vendor
• amount
• currency
• transaction date
• attachment name

Duplicate Statuses

• Exact Duplicate
• Probable Duplicate
• Related Document
• Resent Document
• Not Duplicate

Exact Duplicate
Skip forwarding and storage.
Record the existing document reference.

Probable Duplicate
Queue for review.

Related Refund or Credit
Link to the original expense rather than treating it as a duplicate expense.

=== IDEMPOTENCY RECORD ===

For every document, record:

• source message identifier
• attachment identifier
• attachment hash where supported
• vendor
• amount
• currency
• transaction date
• reference
• destination file
• forwarding status
• storage status
• log status
• final processing status

A completed record must not be processed again.

=== REFUND AND CREDIT HANDLING ===

Refund Flow

Refund Discovered
→ Identify Original Vendor
→ Match Amount or Reference
→ Link to Original Expense
→ Store in Refunds and Credits
→ Forward to Finance
→ Mark Original Relationship
→ Record in Log

Do Not
Count a refund as a new expense.

Unmatched Refund
Store in Exceptions or Refunds and Credits according to policy and mark Original Expense Not Confirmed.

=== SUBSCRIPTION RECEIPT TRACKER ===

Vendor
Adobe

Frequency
Monthly

Expected Date Window
Configured by finance

Expected Currency
USD

Expected Amount
Verified value or approved range

Current Month
Found / Missing / Ambiguous / Refunded

Last Receipt
Verified document reference

At monthly close

• compare expected subscriptions with discovered documents
• identify missing receipts
• identify unexpected duplicate charges
• identify changed amounts for review
• do not assume an amount change is incorrect

=== EXCEPTION QUEUE ===

Exception Types

• Personal or business purpose unclear
• Missing amount
• Missing currency
• Missing date
• Vendor unclear
• Unreadable image
• Password-protected attachment
• Unsupported file
• Probable duplicate
• Multiple transactions in one document
• Refund relationship unclear
• Attachment missing
• Storage failed
• Forwarding failed
• Conflicting fields

Exception Record

Source
[...]

Reason
[...]

Observed Data
[...]

Missing Data
[...]

Proposed Action
[...]

Risk
[...]

Reviewer
[...]

Resolution
[...]

=== PARTIAL FAILURE HANDLING ===

Case
Forwarding succeeds but storage fails.

Action

• retain Forwarded status
• do not forward again automatically
• retry storage only
• record failure
• notify the exception queue

Case
Storage succeeds but forwarding fails.

Action

• retain Stored status
• retry forwarding only
• do not create another file
• record the failure

Case
Processing log fails.

Action

• preserve the successful forwarding and storage states
• create a log-repair task
• do not repeat previous successful actions

=== HISTORICAL BACKFILL PLAN ===

Period
January 1, 2026 to present

Phase 1:
Audit-only discovery

Phase 2:
Review search coverage and exclusions

Phase 3:
Classify business, personal, ambiguous, duplicate, refund, and exception records

Phase 4:
Approve folder and naming behavior

Phase 5:
Store approved historical documents

Phase 6:
Forward only according to finance-approved historical-forwarding policy

Phase 7:
Create backfill reconciliation report

Do not flood the finance inbox with historical documents without explicit approval.

=== MONTHLY CLOSE WORKFLOW ===

1. Confirm the month date range.
2. Review unresolved exceptions.
3. Review probable duplicates.
4. Review refunds and credits.
5. Check expected recurring subscriptions.
6. Identify missing receipts.
7. Review late arrivals.
8. Compare with supplied statement data.
9. Preserve separate currency totals.
10. Create month-end summary.
11. Mark unresolved items.
12. Obtain finance approval where required.

=== MONTH-END SUMMARY ===

Month
July 2026

Documents Discovered
[...]

Business Confirmed
[...]

Forwarded
[...]

Stored
[...]

Duplicates Skipped
[...]

Refunds and Credits
[...]

Late Arrivals
[...]

Missing Expected Receipts
[...]

Exceptions
[...]

Failures
[...]

Unresolved
[...]

Currency Totals
Keep each currency separate unless an approved conversion policy exists.

=== AUDIT LOG FIELDS ===

• processing timestamp
• source message identifier
• sender
• subject
• email received date
• attachment name
• attachment identifier
• vendor
• transaction date
• amount
• currency
• document type
• expense category
• business-purpose confidence
• duplicate status
• refund relationship
• destination
• forwarding status
• storage status
• exception status
• reviewer
• resolution
• final status

=== ACCEPTANCE CRITERIA ===

High-Confidence Receipt

Given an approved vendor sends a valid business invoice,
when the workflow processes the message,
then the document is classified, checked for duplicates, stored in the transaction month, forwarded once to finance, and recorded in the audit log.

Personal Purchase

Given a document contains a strong personal-purchase signal,
when classification runs,
then it is not forwarded automatically and is marked Personal or Needs Review.

Duplicate

Given the same invoice was already processed,
when a resent copy is discovered,
then the workflow does not create another finance forward or stored file.

Late Arrival

Given a July receipt arrives in August,
when the transaction date is reliable,
then the document is stored in the July folder and logged as a late arrival.

Partial Failure

Given forwarding succeeds and storage fails,
when retry processing runs,
then only storage is retried.

Refund

Given a refund matches an earlier expense,
when processing completes,
then the refund is linked to the original record and is not counted as a new expense.

Missing Subscription Receipt

Given an expected monthly subscription receipt is not found,
when monthly close runs,
then it appears in the missing-receipt report without claiming that no charge occurred.

=== REGRESSION TEST MATRIX ===

Document Types

• Receipt
• Invoice
• Payment Confirmation
• Subscription Charge
• Refund
• Credit Note
• Cancellation

Formats

• PDF
• PNG
• JPEG
• HTML Message
• Multiple Attachments
• Multi-Page Document
• Password-Protected File
• Unsupported File

Classifications

• Business
• Personal
• Ambiguous
• Duplicate
• Refund
• Exception

Dates

• Transaction Month
• Late Arrival
• Missing Date
• Conflicting Dates
• Year Boundary

Failures

• Search Failure
• Forward Failure
• Storage Failure
• Folder Creation Failure
• Log Failure
• Partial Failure
• Authentication Failure

Currencies

• USD
• EUR
• GBP
• Multiple Currencies
• Currency Missing

=== QA CHECKLIST ===

Email Search

• Verify date boundaries.
• Verify approved vendors.
• Verify exclusions.
• Verify historical messages.
• Verify already-processed filtering.

Documents

• Verify attachment integrity.
• Verify amount.
• Verify currency.
• Verify date.
• Verify vendor.
• Verify reference.
• Verify document type.

Classification

• Verify business signals.
• Verify personal signals.
• Verify ambiguity handling.
• Verify category.
• Verify confidence.

Duplicates

• Verify source ID.
• Verify attachment hash.
• Verify reference.
• Verify vendor-date-amount comparison.
• Verify resent documents.

Storage

• Verify year folder.
• Verify month folder.
• Verify document subfolder.
• Verify file name.
• Verify no overwrite.
• Verify original document.

Forwarding

• Verify recipient.
• Verify subject.
• Verify body.
• Verify attachments.
• Verify no unrelated content.
• Verify single delivery.

Exceptions

• Verify queue entry.
• Verify reason.
• Verify evidence.
• Verify proposed action.
• Verify final resolution.

Privacy

• Verify masked data.
• Verify approved recipients.
• Verify no credentials.
• Verify no unrelated personal correspondence.
• Verify approved retention.

=== RISKS ===

Risk
Personal receipts are forwarded as business expenses.

Mitigation
Use business-purpose rules and route ambiguous documents to review.

Risk
Finance receives duplicate documents.

Mitigation
Use idempotency records and multi-signal duplicate detection.

Risk
A receipt is filed in the wrong month.

Mitigation
Use transaction date first and record date uncertainty.

Risk
A successful finance forward repeats after a storage failure.

Mitigation
Track forwarding and storage independently.

Risk
A refund is counted as a new expense.

Mitigation
Classify refunds separately and link them to original records.

Risk
Sensitive email content is exposed.

Mitigation
Forward only the relevant document and concise approved metadata.

Risk
Missing receipts are interpreted as missing charges.

Mitigation
Report only that a document was not found; do not claim that no transaction occurred.

=== KNOWN LIMITATIONS ===

• Email and storage access require authorized integrations.
• Document extraction may be incomplete.
• Business purpose may require manual review.
• Tax deductibility requires professional judgment.
• Duplicate detection is probabilistic when identifiers are missing.
• Currency conversion requires an approved policy.
• Reconciliation depends on complete statement data.
• Provider limits and authentication changes may interrupt scheduled processing.
• The workflow does not replace bookkeeping, tax, audit, legal, privacy, or security review.

=== FINAL INTEGRITY NOTE ===

A receipt-like document is not automatically a valid or deductible business expense.

All forwarding recipients, folder destinations, classification rules, accounting periods, tax treatment, retention requirements, refund relationships, and deletion decisions must be verified.

The workflow is designed to improve receipt discovery, monthly organization, traceability, and finance-team efficiency. It does not guarantee accounting completeness, tax compliance, fraud detection, or successful reconciliation.