<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>AutoFileEmail</title>
        <link>https://autofile.email</link>
        <description>Auto-save every receipt and invoice from Gmail or Outlook into your own Drive folder. Organized by vendor and date. No OCR. No AI. Just files.</description>
        <lastBuildDate>Thu, 01 Oct 2026 08:50:10 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <copyright>2026</copyright>
        <item>
            <title><![CDATA[Save Gmail Attachments to Google Drive Automatically (2026 Guide)]]></title>
            <link>https://autofile.email/blog/save-gmail-attachments-to-google-drive-automatically</link>
            <guid isPermaLink="false">https://autofile.email/blog/save-gmail-attachments-to-google-drive-automatically</guid>
            <pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Tired of right-clicking Save As on every Stripe and AWS invoice? Here's how to auto-file Gmail attachments into Drive folders, organized by sender domain.]]></description>
            <content:encoded><![CDATA[Guide to automatically saving Gmail attachments to Google Drive in 2026 with Studio Ghibli-inspired coziness

It's a Sunday in April. You're trying to do your taxes.

You search Gmail for has:attachment from:stripe. 47 results. You click the first one. Right-click the PDF. "Save link as." Pick a folder. Rename the file because Stripe calls every invoice invoice.pdf. Switch to Drive. Drag it in. Click into the next email.

You do this 46 more times. Then you do it again for AWS. Then for Notion. Then for the Adobe sub you forgot about.

Three hours later you've filed maybe 80 attachments and your back hurts.

There's a better way. Actually, there are several. Most of them are bad. One is good. Here's the full picture.

Table of Contents

Why this is a problem worth fixing
Option 1: Gmail's built-in "Save to Drive"
Option 2: Gmail filters
Option 3: Zapier or IFTTT
Option 4: Google Apps Script
Option 5: Auto-file by sender domain
What about per-email fees?
Setup, end to end
What about Outlook? iCloud? IMAP?
The bottom line

Why this is a problem worth fixing

The average solo founder gets receipts from 15 to 30 vendors a year. Stripe payouts. AWS bills. Cursor, Linear, Notion, Vercel, Adobe, Figma, GitHub, Postmark, Resend, Cloudflare, every domain registrar you've ever used.

Each one mails you a PDF. Each PDF is one click away from being filed. But "one click" times "30 vendors" times "12 months" is 360 clicks a year just to keep your invoices in Drive.

Nobody does that. So nobody has their invoices in Drive. So everybody scrambles in April.

The goal is simple: when an email with a PDF attachment lands in Gmail, the PDF should automatically end up in a Drive folder. Organized so you can find it later. Without you doing anything.

Sounds basic. Ends up being weirdly hard.

Frustrated founder with Gmail inbox clutter showing has:attachment from:stripe

Option 1: Gmail's built-in "Save to Drive"

Gmail does have a "Save to Drive" button. Hover over an attachment, it appears.

Two problems.

First, it's manual. You still have to open every email. We're back to 360 clicks.

Second, it dumps everything into one folder by default. So your Drive ends up with 400 files named invoice.pdf, invoice (1).pdf, invoice (2).pdf, all in My Drive. Useless.

You can move them around manually. But then you're sorting files by hand, which is the original problem in a different shirt.

Option 2: Gmail filters

Gmail filters can do a lot. Label, archive, mark as read, forward, skip the inbox.

What they cannot do: download an attachment to Drive.

That's it. That's the section.

You can label every Stripe email and tell yourself you'll batch-process them later. You won't. The label exists for the same reason the unread folder exists: as a graveyard for tasks you'll never do.

Option 3: Zapier or IFTTT

This is where most "save Gmail attachments to Drive" articles end. They tell you to wire up a Zap and call it a day.

Here's what actually happens.

Zapier's "New Attachment in Gmail" trigger to "Upload File in Google Drive" action works. For one folder. Per Zap.

So if you want stripe.com attachments in Drive/Stripe/, you build a Zap. If you want aws.amazon.com attachments in Drive/AWS/, you build another Zap. Each Zap matches one sender, lands in one folder.

You have 30 vendors. You'd need 30 Zaps. Zapier's free plan caps you at 5 Zaps and 100 tasks a month. The Starter plan is $19.99/mo for 750 tasks. The Professional plan is $49/mo. And every PDF that hits any Zap eats a task.

Plus, Zapier has no concept of "file by sender domain into a folder hierarchy." You have to hard-code the folder. So when a new vendor emails you for the first time, nothing happens. The PDF just sits in Gmail unfiled. Same problem as Gmail filters, but with a $50/mo invoice attached.

IFTTT has the same shape. Different pricing, same limitation.

Automation flow from Gmail to Drive using Zapier/IFTTT visualization

Option 4: Google Apps Script

If you can write JavaScript, you can solve this with Apps Script. Open a script, query Gmail with GmailApp.search, iterate attachments, save to Drive with DriveApp.createFile.

Total cost: zero dollars and roughly two evenings.

Then it breaks. Apps Script has a 6-minute execution timeout. If you have a backlog, it doesn't finish. Refresh tokens expire. Drive folder lookups time out. The script silently fails and you don't know until tax season when you go looking for the receipts.

If you're a developer and you like maintaining one more side-thing, sure. Otherwise this is a lot of evenings to file PDFs.

Developer coding Google Apps Script to automate Gmail attachments to Drive

Option 5: Auto-file by sender domain

This is the version we built. Disclosure first: it's our product. Then the explanation, because the mechanism matters even if you build it yourself.

You connect Gmail. You connect Drive. AutoFileEmail watches your inbox. When a new email with an attachment arrives, it does three things:

Looks at the sender. Pulls the registrable domain. So noreply@billing.stripe.com becomes stripe.com. bills@aws.amazon.com becomes amazon.com.
Builds a folder path: /AutoFileEmail/stripe.com/2026/04/.
Saves the attachment there. With the original filename, prefixed by the email date.

Real example. Stripe sends a payout invoice on April 14, 2026. Subject: "Your invoice from Stripe". Attachment: invoice.pdf.

It lands in Drive at /AutoFileEmail/stripe.com/2026/04/2026-04-14-invoice.pdf.

No vendor list to maintain. No Zap to build for each new sender. The first time Postmark emails you, a postmark.com folder appears. The first time some new SaaS you signed up for last week sends a receipt, that folder appears too.

When tax time rolls around, you open Drive, sort by folder, and your CPA gets a clean per-vendor breakdown. That's it. That's the workflow.

AutoFileEmail workflow visual routing emails to Drive by sender domain

What about per-email fees?

This is the part where most filing tools go sideways. Hubdoc, Dext, Receipt Bank, AutoEntry. They charge per receipt scanned, or per inbox, or both. Hubdoc bundles into QuickBooks Online at $35+/mo. Dext starts at $26/mo and meters by document count.

Why? Because they OCR every receipt. Read the line items. Extract amounts. That costs them GPU time. They pass the cost to you.

We don't OCR. The PDF in your Drive folder is the same PDF Stripe sent. We're not reading your receipts, we're just filing them. No GPU bill, no per-email fees. The free tier is free for one inbox forever.

If you want OCR, your accountant's software does it better than any of these tools anyway. Filing is the part that's actually missing.

Clean Drive inbox after automation scene

Setup, end to end

For the version that exists:

Sign up at autofile.email with Google. 30 seconds.
Click "Connect Drive". Approve the drive.file scope (we can only see folders we created, never the rest of your Drive).
Click "Connect Gmail". Approve read-only access.
Done. New attachments start filing within 30 seconds of arriving.

If you signed up today, you also get a 30-day historical preview. So the last month of receipts files itself retroactively without you doing a thing.

If you want the last 3 years filed too, that's the $29 Tax Year Pack or $59 3-Year Pack. One-time payment, no subscription.

What about Outlook? iCloud? IMAP?

All shipped. The product is provider-agnostic on both sides now: pick any inbox, pick any cloud.

Inboxes: Gmail, Outlook (Microsoft Graph), or IMAP (iCloud Mail, Fastmail, Yahoo, Zoho, Proton Bridge, Yandex, and any host that speaks IMAP with an app password).
Clouds: Google Drive (drive.file), OneDrive (App folder), or Dropbox (App folder).

The folder layout is the same wherever files land: /AutoFileEmail/{sender-domain}/{YYYY}/{MM}/. So if you ever swap any leg of the stack - Gmail to Outlook, Drive to OneDrive - your accountant doesn't have to relearn anything.

A few combo-specific walkthroughs if you're not on Gmail+Drive:

Save Outlook attachments to OneDrive
Save Gmail attachments to OneDrive
Save Gmail attachments to Dropbox
Auto-file iCloud Mail attachments via IMAP

The one-page setup for this exact pairing is the Gmail + Google Drive integration. The full integrations matrix lives at /integrations.

The bottom line

The manual workflow costs you 3 hours a year and a missing receipt or two when it counts.

Gmail filters can't do it. Zapier can do it badly for $50/mo. Apps Script works until it doesn't. AutoFileEmail does the one specific job: PDF lands in Gmail, PDF lands in Drive, organized by sender domain, no clicks.

Connect Gmail in 30 seconds. Free for one inbox. If you're a freelancer, the tax-time workflow is built around this exact filing pattern.

Try it. Worst case you save an hour next April.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/save-gmail-attachments-to-google-drive-automatically/save-gmail-attachments-drive-automatically-2026-banner-2f82bf58-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Save Outlook Attachments to OneDrive Automatically (2026 Guide)]]></title>
            <link>https://autofile.email/blog/save-outlook-attachments-to-onedrive-automatically</link>
            <guid isPermaLink="false">https://autofile.email/blog/save-outlook-attachments-to-onedrive-automatically</guid>
            <pubDate>Thu, 07 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Outlook attachments pile up in your inbox. Here's how to auto-file them into OneDrive by vendor and date - no Power Automate flows, no custom expressions.]]></description>
            <content:encoded><![CDATA[Guide to saving Outlook attachments to OneDrive automatically with AutoFileEmail in 2026

It's a Tuesday. You open Outlook and search hasattachments:yes from:stripe. 38 results.

You right-click the first attachment. "Save As." Browse to OneDrive. Pick a folder. Rename the file because Stripe calls every invoice invoice.pdf. Switch back to Outlook. Open the next email.

You do this 37 more times. Then again for AWS. Then for Adobe, Notion, Linear, Cursor, Vercel, Postmark, your domain registrar, every SaaS subscription you've signed up for since January.

Two and a half hours later, you've filed maybe 60 PDFs and your wrist hurts.

There is a better way. Microsoft will tell you the answer is Power Automate. They are technically correct and practically wrong. Here's the full picture, including the version that actually ships.

Table of Contents

The native Outlook + OneDrive answer is "kind of"
What Power Automate actually costs you
What we built instead
Setup, end to end
App folder mode: we cannot see anything else
What about M365 work accounts?
What we don't do
TL;DR

The native Outlook + OneDrive answer is "kind of"

Microsoft does have a story here. Two of them, actually.

The first is "Save to OneDrive" right inside Outlook. You hover over an attachment, click the OneDrive icon, and the file lands in your Email attachments folder. One click instead of three.

The problem is that "one click" times "30 vendors" times "12 months" is still 360 clicks a year, and they all pile into the same flat folder. By April you've got invoice.pdf, invoice (1).pdf, ... invoice (47).pdf. Useless to your accountant.

The second answer is Outlook rules. Rules can do a lot - move messages, set categories, forward, mark as read. They cannot save an attachment to OneDrive. That's not a feature. It has never been a feature. Microsoft's recommended fix is to forward the message to Power Automate.

So we end up at Power Automate. Which is where most blog posts about this stop, with the words "and that's how easy it is to save Outlook attachments to OneDrive!" Reader, it is not easy.

Illustration of Outlook + OneDrive native integration described as 'kind of' in a cozy workstation

What Power Automate actually costs you

Power Automate's free tier (bundled with M365) gives you 750 actions per day per user. Sounds like a lot. It isn't.

Each "save to OneDrive" run uses at least three actions: trigger fires, get-attachment, create-file. A heavy-receipt user with 30 vendors emailing 5+ PDFs each in a busy month chews through 750 actions in a couple of weeks.

When you blow the limit, your flow doesn't just stop - it queues. Filings show up days late. By the time you notice, you've already missed a tax-deductible receipt that lived in your inbox for 72 hours and got auto-archived.

The fix is Power Automate Premium, which starts at $15/user/month. That's more than AutoFileEmail Pro will cost when it ships.

There's also the build cost. The default "Save Outlook attachments to OneDrive" template dumps everything in one folder. To get vendor-domain folders like /stripe.com/2026/05/, you have to write custom expressions:

split(triggerOutputs()?'body/from'], '@')[1]

Then nested if() calls to strip mail., noreply., notifications. prefixes from sender domains, because notifications.aws.amazon.com should land in aws.amazon.com, not its own folder.

The expression language gets ugly fast. Most people give up around the third nested if() and accept that noreply.stripe.com and stripe.com will be separate folders forever. Now your accountant has 80 folders instead of 30. Worse, not better.

For a deeper look at why these duct-tape automations cost more than purpose-built tools, see [the Outlook + OneDrive freelancer's filing setup.

Cost and complexity of Power Automate illustrated with a '750 actions/day' concept

What we built instead

You connect Outlook. You connect OneDrive. AutoFileEmail watches your inbox. When a new email with an attachment arrives, three things happen:

We pull the registrable sender domain. noreply@billing.stripe.com becomes stripe.com. bills@aws.amazon.com becomes amazon.com. The hand-coded prefix-stripping that nobody wants to write in Power Automate, we do for you.
We build the folder path: /Apps/AutoFileEmail/stripe.com/2026/05/.
We save the attachment there with the original filename, prefixed by the email date.

A real example. Stripe sends a payout invoice on May 7, 2026. Subject: "Your invoice from Stripe." Attachment: invoice.pdf.

It lands in OneDrive at /Apps/AutoFileEmail/stripe.com/2026/05/2026-05-07-invoice.pdf.

No vendor seed list to maintain. No expression to debug. The first time Postmark emails you, a postmark.com folder appears. The first time some new SaaS you signed up for last week sends a receipt, that folder appears too.

When tax time rolls around, you open OneDrive, navigate to Apps > AutoFileEmail, and your CPA gets a clean per-vendor breakdown. That's the whole workflow.

Diagrammatic representation of the AutoFileEmail workflow behind the scenes

Setup, end to end

The actual click-by-click for Outlook + OneDrive:

Sign up at autofile.email with your Microsoft account. 30 seconds.
Click "Connect Outlook." Microsoft consent screen. Approve Mail.Read (we read mail and download attachments, that's it).
Click "Connect OneDrive." Second consent screen. Approve "Have full access to the application's folder."
Done. AutoFileEmail starts polling within 30 seconds of you finishing onboarding.

If you signed up today, you also get a 30-day historical preview free. Last month's receipts file themselves retroactively without you doing a thing.

If you want the last full tax year filed too, buy the $29 Tax Year Pack. One-time payment, no subscription. Backfill runs in the background; you can close the tab.

The full setup walkthrough lives on the Outlook + OneDrive integration page.

Onboarding steps for AutoFileEmail: sign up, connect Outlook, connect OneDrive, done

App folder mode: we cannot see anything else

This part matters more than people realize.

OneDrive has a permission scope called Files.ReadWrite.AppFolder. It's the narrowest scope Microsoft offers for OneDrive. Translated: AutoFileEmail can create, read, update, and delete files inside /Apps/AutoFileEmail/. We cannot see, list, or touch anything else in your OneDrive. The Microsoft Graph API will refuse if we try.

Your family photos, your work docs, your half-finished pitch decks, the Documents folder, the desktop sync, the Personal Vault - all invisible to us. Not "we promise not to look." Literally not in the API surface we have access to.

Compare that to Hubdoc, Dext, or any of the OCR-based receipt tools. They want broad inbox access AND broad file access. They scrape every receipt, send it through GPU-backed OCR, and store the parsed line items. The trade is "give us your data, we give you searchable receipts." We don't make that trade. We just file the PDFs Stripe sent you, in the folders your accountant wants to see them in.

The /Apps/ prefix in OneDrive is a real-world consequence of this sandbox. If you've ever connected another Files.ReadWrite.AppFolder app, you've already got an Apps folder; AutoFileEmail just adds a sibling subfolder.

OneDrive AppFolder mode highlighted with a calm, privacy-focused scene

What about M365 work accounts?

If your inbox is at a Microsoft 365 work account (yourname@yourcompany.com), there's an extra step: many enterprise tenants block third-party apps by default. The consent screen will say "Approval required" and the connection fails until your IT admin grants tenant or per-user consent.

The good news is the scopes we ask for are narrower than what tools like Power Automate, Zapier, or Hubdoc request. Most IT teams approve Mail.Read + Files.ReadWrite.AppFolder without much pushback because the footprint is genuinely small.

For solo founders running a single-user M365 tenant (you're the admin), this is just one extra "Consent on behalf of your organization" checkbox during onboarding. Tick it. Done.

What we don't do

A few things worth being explicit about, because the receipt-filing category is full of tools that quietly do more than you'd expect:

No OCR. The PDF in your OneDrive folder is the same PDF Stripe sent. We don't parse line items. We don't extract amounts. We don't categorize. Your accountant's software does that better than any of these tools, and we're not reading your receipts - we're just filing them.
No outbound mail. Mail.Read only. We can't send, reply, forward, or mark as read.
No per-email metering. The free tier files unlimited new attachments going forward. The Backfill Packs are the only paid product, and they're one-time, not subscription.
No Cash App Pay. Standard checkout, Stripe-backed.

If you want OCR, your accountant's software does it better than any of these tools. Filing is the part that's actually missing for most people.

TL;DR

Outlook's native "Save to OneDrive" is a one-click flat dump. Doesn't scale past 50 receipts.
Outlook rules can't save attachments. Microsoft's official fix is Power Automate.
Power Automate's free tier (750 actions/day) runs out in busy months; Premium is $15/user/month. Vendor-domain routing requires custom expressions that nobody enjoys writing.
AutoFileEmail's Outlook + OneDrive setup: two OAuth screens, files land under /Apps/AutoFileEmail/{vendor}/{YYYY}/{MM}/, free for one inbox.
App folder mode means we literally cannot see anything else in your OneDrive.

Free for one inbox + one cloud. 30-day historical preview included. The $29 Tax Year Pack covers a full year of backfill if you want April's receipts already filed.

We don't read your receipts. We just file them. Try it - worst case, you save an hour next April.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/save-outlook-attachments-to-onedrive-automatically/save-outlook-attachments-one-drive-automatically-2026-banner-864869a6-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[How Freelancers Actually File Receipts (No Apps, No Spreadsheets)]]></title>
            <link>https://autofile.email/blog/how-freelancers-actually-file-receipts</link>
            <guid isPermaLink="false">https://autofile.email/blog/how-freelancers-actually-file-receipts</guid>
            <pubDate>Fri, 08 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Freelancers don't need Hubdoc or a 12-tab spreadsheet. Here's the minimum-viable receipt system: connect Gmail, files arrive in Drive by sender. 2 minutes.]]></description>
            <content:encoded><![CDATA[Freelancer receipt filing made simple with a Studio Ghibli vibe and warm pastels

Meet Sara. Web designer. Two years freelance. Works on Upwork, takes Stripe payouts, runs Adobe Creative Cloud, hosts client sites on AWS, uses Notion for everything else.

Last March, Sara paid an accountant $400 to do her taxes. The accountant asked for receipts. Sara opened Gmail.

What followed was 6 hours of: search a sender, download PDFs one by one, rename them, drop them into a folder called "2025 receipts" on Desktop, zip the folder, email it to her CPA. Then realize she forgot Figma. Then realize she forgot the domain registrar. Then realize Stripe payouts aren't even receipts, they're income statements, and she'd been mixing them up the whole time.

Sara is not bad at her job. She is bad at the part of her job that nobody trained her for.

This post is the system I'd give Sara. No apps, no spreadsheets, no accountant overrides. The minimum that survives a CPA handoff.

Table of Contents

Why most "receipt systems" don't work for freelancers
What freelancers actually need
The folder structure
How to actually populate that folder structure
What about the 3 years of stuff already in your inbox?
What about income? 1099s? Bank statements?
Common objections
The bottom line

Why most "receipt systems" don't work for freelancers

The receipt-management software you find when you Google for it - Hubdoc, Dext, Receipt Bank, AutoEntry - is built for accounting firms. Specifically, accounting firms with 50 small business clients who all need their receipts categorized, line-item-extracted, and exported to QuickBooks for monthly bookkeeping.

You are not an accounting firm. You're one person. You don't do monthly bookkeeping. You hand a folder of PDFs to a CPA once a year, and they figure out the schedule C.

The tools designed for the firms cost $26 to $35 a month, run OCR on every receipt, and give you a categorized data export you don't need. It's like buying a forklift to move one box.

Spreadsheets are the other instinct. Open Sheets. Column for date, vendor, amount, category. Type each receipt in.

You will not do this. Nobody does this. By month two you're behind. By month four you've abandoned it. By March you have a half-filled spreadsheet and 200 PDFs scattered across Downloads, Gmail, and a folder called "stuff."

The system has to require zero ongoing effort, or the system doesn't survive contact with the actual freelance year.

What freelancers actually need

Three things. In order of importance:

The PDFs exist somewhere your CPA can access. Not "in Gmail." A folder. A real one.
They're sorted by vendor. So your CPA sees Stripe stuff together, AWS stuff together, Adobe stuff together.
They're sorted by year. So 2025 receipts don't mix with 2024 receipts.

That's it. That's the entire spec.

You don't need categories. Your CPA does that. You don't need amounts extracted. Your CPA does that. You don't need OCR. Your CPA reads the PDF.

You need the PDF to exist, in a folder, organized by who sent it and when.

Organizer setting up a vendor-year folder structure for receipts

The folder structure

/AutoFileEmail/
  stripe.com/
    2026/
      04/
        2026-04-14-payout-summary.pdf
        2026-04-30-payout-summary.pdf
  aws.amazon.com/
    2026/
      04/
        2026-04-03-bill.pdf
  adobe.com/
    2026/
      04/
        2026-04-12-invoice.pdf

Three levels: vendor, year, month. Files inside. Done.

When your CPA asks "did you have any AWS expenses in Q1?", you click into aws.amazon.com/2026/, see folders for 01, 02, 03. Three PDFs. Send.

When the IRS asks you to substantiate a $48 charge from Adobe in April 2026 (which they won't, but hypothetically), you click into adobe.com/2026/04/. There it is.

This structure also reads well to humans. You don't need a legend. You don't need to learn anything. The folder names are the vendor names.

Folder-tree structure showing vendor/year/month

How to actually populate that folder structure

Three options, ranked by effort.

Option A: Manually, every Sunday.

Open Gmail. Search has:attachment newer_than:7d. Click each email. Save attachment. Drag to right Drive folder. Repeat.

Works for the first three weeks. Falls off in week four. You're back to "I'll batch it before April."

Option B: Apps Script or Zapier.

If you're technical, write a script. Six-minute timeout, brittle, breaks quietly. If you're not, a Zap per sender at $20/mo for the cheap plan that doesn't actually cover 30 vendors. Detailed breakdown is in our Gmail to Drive automation guide.

Option C: Connect Gmail and Drive once. Done.

This is what AutoFileEmail does. The setup is two clicks: approve Gmail read-only access, approve Drive drive.file scope. After that, every new email with an attachment lands in the folder structure above. Sender domain becomes folder name. Year and month auto-populate.

The bet is: you do this once, on a Tuesday, in two minutes. Then the system runs for the rest of your freelance career and you stop thinking about it.

Populate-folder-structure-drive-gmail

What about the 3 years of stuff already in your inbox?

This is the part nobody addresses. You can build the perfect forward-going system, but you still have a wall of historical receipts to deal with.

We added Backfill Packs for this. One-time purchase, runs against a date range you pick. The $29 Tax Year Pack processes one tax year of email backwards. The $59 3-Year Pack does three. The $99 Lifetime Pack does everything in your Gmail history (capped at 50,000 emails, hard stop).

Sara, the freelancer above, would buy the 3-Year Pack. Connect Gmail. Pick "January 1 2023 to today." Walk away. Come back to a fully filed Drive.

There's a free 30-day historical preview included on signup, so you can see whether the system actually finds your receipts before paying. If your vendor mix is weird and we miss things, don't pay.

What about income? 1099s? Bank statements?

AutoFileEmail handles deductible expenses. The receipts you'd need at audit. The PDFs vendors email you.

It does not handle:

1099 income forms (your clients send those, often via paper or weird tax-software portals)
Bank statements (banks rarely email PDFs)
Cash transactions
Mileage

Those stay manual. A separate "Income" folder in Drive, populated once a year. That's fine. Income is 5 to 10 documents for most freelancers. Expenses are 200 plus. Solve the 200, leave the 5 alone.

This is covered in more depth in the 3 folders that survive an audit, if you want the full structure.

Common objections

"I just use my email as my filing system."

You don't. You use Gmail search as a substitute for filing, and it works until it doesn't. Random label decay, filters that get edited, archived threads that fall out of date searches. Try finding every Stripe payout from 2023 right now. Did all 12 monthly payouts come back? Probably not.

"I have a bookkeeper for that."

A bookkeeper is great for monthly reconciliation. They're not the right person to chase down every PDF in your inbox. You hand them organized files; they categorize and reconcile. Right input, right output.

"I'll deal with it in March."

Sure. But March-you is still going to need the PDFs. Filing them now costs zero seconds because the system runs without you. Filing them in March costs 6 hours and at least one missed receipt. The math is obvious; the discipline isn't.

The bottom line

You don't need an app. You don't need a spreadsheet. You need PDFs in Drive, sorted by vendor, sorted by year.

Set it up once. Forget about it. Hand the folder to your CPA in March.

If you're a freelancer and want the full setup walkthrough, the freelancer solution page has the step-by-step. Or just connect Gmail at autofile.email and start filing in two minutes. Free for one inbox. No subscription.

Sara would have saved $400 in CPA hourly billing this year, plus a Sunday afternoon. Yours is probably worth more than hers.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/how-freelancers-actually-file-receipts/how-freelancers-actually-file-receipts-banner-cb6a8f22-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Save Gmail Attachments to OneDrive Automatically]]></title>
            <link>https://autofile.email/blog/save-gmail-attachments-to-onedrive-automatically</link>
            <guid isPermaLink="false">https://autofile.email/blog/save-gmail-attachments-to-onedrive-automatically</guid>
            <pubDate>Fri, 08 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Gmail for email, OneDrive for files? Here's how to auto-file Gmail attachments into OneDrive by vendor and date - the cross-cloud setup most tools skip.]]></description>
            <content:encoded><![CDATA[Automatic saving of Gmail attachments to OneDrive with a cross-cloud workflow

"My team uses Gmail, but our work files live in OneDrive."

I've heard this sentence from a dozen small-business owners in the last six months. It's surprisingly common. The split is real and it's annoying.

Email runs on Google Workspace because Gmail's spam filter is unbeatable and the price is right. Files run on OneDrive because Microsoft 365 came bundled with the Surface laptops, or because the bookkeeper wanted Excel, or just because that's where the company's documents have lived since 2018.

Now you want receipts auto-filed. Gmail receipts. Going into OneDrive. By vendor.

Native Microsoft tooling can't help you - Power Automate's Gmail connector is awkward and incomplete. Native Google tooling can't help you either - Drive doesn't talk to OneDrive. You're in the cross-cloud middle, and most receipt-filing tools quietly assume your inbox and your file storage are on the same vendor.

This post is the working setup for the cross-cloud case.

Table of Contents

Why this combo is more common than it sounds
Why Power Automate's Gmail connector is awkward
How AutoFileEmail handles the split
Where files actually appear in OneDrive
App folder mode: the privacy benefit of split-cloud
Setup, end to end
What about M365 work accounts?
What this is NOT
TL;DR

Why this combo is more common than it sounds

There's a stereotype that "Gmail people use Drive, Outlook people use OneDrive." Real life is messier.

The Gmail-on-mail / Microsoft-on-files split shows up most often in:

Small businesses on Google Workspace email but Microsoft 365 Business for Office. The bookkeeper insisted on Excel. The CFO wanted SharePoint. Email stayed on Workspace because nobody wanted to migrate aliases.
Solo founders who started on personal Gmail and bought a Surface laptop. OneDrive came pre-installed. They never moved off it.
Agencies sharing files with enterprise clients. Client uses OneDrive. You have to too. But your own email is on Gmail because that's just where it's been forever.
Founders who use Gmail for inbound (better spam filtering) and OneDrive for outbound (clients send Word docs, not Google Docs).

In all four cases, receipts hit Gmail and the bookkeeper wants them in OneDrive. The bridge is what's missing.

Common Gmail and OneDrive cross-cloud usage among small businesses

Why Power Automate's Gmail connector is awkward

Microsoft's Power Automate has a Gmail connector. You'd think this solves it.

It mostly doesn't, for a few reasons:

It's a Premium-tier connector. Gmail is "Premium" in Power Automate's pricing model, which means you need a paid Power Automate license. Starts at $15/user/month for the per-user plan. More than AutoFileEmail Pro will be.
The trigger polls slowly. Power Automate's Gmail trigger fires on a schedule, not a push notification. Default poll is every 3 minutes; high-volume tiers go to 1 minute. Real Gmail push (via Pub/Sub) isn't supported.
No domain routing out of the box. Same story as Outlook + OneDrive. The default template dumps everything into one folder. Vendor folders require custom expressions, nested if() statements to strip subdomains, and hand-coded month/year formatting.
OAuth gets messy. You're authenticating Microsoft (to run Power Automate) AND Google (to read Gmail). When either token expires, the flow silently breaks. You don't know until tax time when receipts stop showing up.

For "wire up one specific sender to one specific folder," it works. For "all receipts, all vendors, all months, organized," it falls apart fast.

Awkwardness of Power Automate Gmail connector depicted

How AutoFileEmail handles the split

The split-cloud case is exactly what we built for.

AutoFileEmail's onboarding lets you pick any inbox and any cloud independently:

Inbox tile: Gmail, Outlook, IMAP
Cloud tile: Google Drive, OneDrive, Dropbox

Pick Gmail. Pick OneDrive. The product treats them as separate OAuth flows with separate consent screens.

You'll see two windows during onboarding:

Google sign-in window for Gmail. Approve Gmail's read scope (read mail and download attachments).
Microsoft sign-in window for OneDrive. Approve Files.ReadWrite.AppFolder (read/write only inside /Apps/AutoFileEmail/).

Two minutes, two consent screens, done. AutoFileEmail polls Gmail every 30 seconds. New attachments file into OneDrive at /Apps/AutoFileEmail/{vendor-domain}/{YYYY}/{MM}/.

For the cross-cloud user, this is the whole story. The product abstracts away the fact that your email is on one vendor and your files are on another.

AutoFileEmail bridges Gmail and OneDrive for cross-cloud filing

Where files actually appear in OneDrive

Open OneDrive on the web. Click "My files" in the left nav. Scroll to the Apps folder. Inside it, AutoFileEmail. That's our sandbox.

Inside /Apps/AutoFileEmail/, after a couple of weeks of filing:

/Apps/AutoFileEmail/
  amazon.com/
    2026/
      05/
  stripe.com/
    2026/
      04/
        2026-04-14-invoice.pdf
      05/
        2026-05-02-invoice.pdf
  notion.so/
    2026/
      05/
  vercel.com/
    2026/
      05/
  cursor.sh/
    2026/
      05/

One folder per registrable sender domain. Year and month subfolders. Original filenames, prefixed by the email date so they sort cleanly.

Same structure as Gmail+Drive, same structure as Outlook+OneDrive. If you ever switch any leg of the stack, your accountant doesn't have to learn anything new.

Receipts organized under Apps/AutoFileEmail in OneDrive

App folder mode: the privacy benefit of split-cloud

The OneDrive scope we ask for - Files.ReadWrite.AppFolder - is the narrowest one Microsoft offers. We can read and write inside /Apps/AutoFileEmail/. We literally cannot see anything else in your OneDrive. The Graph API refuses if we try.

For the cross-cloud user, this is a real privacy upgrade. Your work files in OneDrive are visible only to your work tools and the people you've shared them with. AutoFileEmail isn't on the list. We don't have access to read them, list them, or even know they exist.

Same pattern on the Gmail side. We ask for the read-only Gmail scope. We don't ask for gmail.send or gmail.modify. We can read mail and download attachments. We can't reply, forward, mark as read, or change anything in your inbox.

If your IT department or your clients have asked you not to give third parties broad access to either cloud, this scope footprint usually clears the bar without much pushback. For the same reason we don't OCR your receipts, the App folder scope is the only OneDrive scope we want - smallest blast radius if a token ever leaks.

App folder mode privacy split cloud

Setup, end to end

Click-by-click for the Gmail + OneDrive combo:

Sign up at autofile.email. Pick Google sign-in or magic email.
Click "Connect Gmail." Google consent screen. Approve Gmail read access.
Click "Connect OneDrive." Microsoft consent screen. Approve Files.ReadWrite.AppFolder and User.Read.
Done. AutoFileEmail starts polling within 30 seconds.

If you signed up today, the 30-day historical preview backfill kicks off automatically. April's receipts populate in OneDrive within a few minutes.

If you want a full tax year filed, the $29 Tax Year Pack covers it. One-time. No subscription. Backfill runs in the background.

Full walkthrough on the Gmail + OneDrive integration page.

What about M365 work accounts?

If your OneDrive is connected to a Microsoft 365 work tenant (yourname@yourcompany.com), there's an extra step: many enterprise tenants block third-party apps. The consent screen will say "Approval required" and the connection fails until your IT admin grants consent.

The scopes we ask for are narrower than what Power Automate, Zapier, or any OCR-based receipt tool would request. Files.ReadWrite.AppFolder reads as "Have full access to the application's folder" on the consent screen, which is accurate - we have full access to OUR folder, no access to anything else.

Most IT teams approve this without much fuss. If you're a solo founder running your own single-user tenant, you're the admin; the extra screen is just a checkbox during onboarding.

What this is NOT

A few things worth being explicit about:

Not OCR. The PDF in OneDrive is the same PDF Stripe sent. We don't parse line items. Your accountant's software does that better.
Not a "scan once and discard" service. The original attachments stay in your inbox. We just copy them.
Not subscription-billed for new mail. Free tier files unlimited new attachments going forward. The only paid product is Backfill Packs (one-time, $29 / $59 / $99).
Not multi-cloud at once on free tier. One inbox + one cloud per account. Pro (5 inboxes, custom destinations, $14.99/mo, coming soon) handles multi-cloud per user.

For a deeper take on why we'll never charge per email scanned, see the Outlook + OneDrive freelancer's filing setup - same logic applies to the cross-cloud case.

TL;DR

Gmail + OneDrive is a real-world combo for plenty of small businesses, agencies, and solo founders.
Power Automate's Gmail connector is Premium-only ($15/user/mo+), polls slowly, and doesn't do vendor-domain routing without custom expressions.
AutoFileEmail's onboarding treats inbox and cloud as independent OAuth flows. Two consent screens, files land under /Apps/AutoFileEmail/{vendor}/{YYYY}/{MM}/ in OneDrive.
App folder mode means we cannot see anything else in your OneDrive. Gmail read-only means we can't change anything in your inbox.
Free for one inbox + one cloud.  The $29 Tax Year Pack covers retroactive filing.

Free for one inbox + one cloud, no credit card. 30-day historical preview included. Connect Gmail and OneDrive in two minutes and watch your inbox stop being a tax-time emergency.

We don't read your receipts. We just file them.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/save-gmail-attachments-to-onedrive-automatically/save-gmail-attachments-to-onedrive-banner-1e5c2744-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Save Gmail Attachments to Dropbox Automatically]]></title>
            <link>https://autofile.email/blog/save-gmail-attachments-to-dropbox-automatically</link>
            <guid isPermaLink="false">https://autofile.email/blog/save-gmail-attachments-to-dropbox-automatically</guid>
            <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Gmail for email, Dropbox for files? Here's how to auto-file Gmail attachments into Dropbox by vendor and date - no Zapier, no per-email task fees.]]></description>
            <content:encoded><![CDATA[Gmail + Dropbox automation banner for saving attachments

Dropbox is the default for many teams. The muscle memory is strong.

Your artist friends are on it. Your editor sends you Word docs through it. Your client folders go back to 2019 and renaming the root would break a hundred shared links. Dropbox is where files live. Drive and OneDrive are interlopers.

Meanwhile, your email is on Gmail because Gmail's spam filter is unbeatable and the price is right. So your receipts hit Gmail and you want them filed in Dropbox. By vendor. So your accountant gets a clean breakdown next April.

This is the Gmail + Dropbox playbook. Two OAuth screens, no Zapier, no third-party automation tax.

Table of Contents

Why Gmail + Dropbox is the agency-and-creative default
Why Zapier and Power Automate don't fix it
How AutoFileEmail handles Gmail + Dropbox
Where files actually appear in Dropbox
App folder mode: Dropbox's privacy sandbox
Setup, end to end
Why this beats forwarding to Dropbox's + email
What about Pro?
TL;DR

Why Gmail + Dropbox is the agency-and-creative default

The Gmail + Dropbox combo is heavily over-represented in three groups:

Creative agencies. Dropbox's file-sharing UX is still the cleanest for swapping 4GB Photoshop files with clients. Email runs on Workspace because Gmail's threading and search beat Outlook's.
Photographers, videographers, podcasters. Big files, lots of clients, deep Dropbox history. Some of them have been on Dropbox since 2009 and they're not switching.
Indie consultants and freelancers. Started on personal Gmail. Started on personal Dropbox. The two have been the stack since the beginning. Drive feels like the new kid; OneDrive feels like work.

In all three cases, receipts hit Gmail and the bookkeeper (or the future-self-doing-taxes) wants them in Dropbox alongside the rest of the year's files.

The native answer to this is "right-click each attachment, Save As, drop in Dropbox." Which works until receipt 30, at which point you stop doing it for the year and your inbox becomes the de-facto filing cabinet again.

Diverse creative team at a desk with Gmail and Dropbox icons illustrating the Gmail + Dropbox default for agencies

Why Zapier and Power Automate don't fix it

Most "save Gmail attachments to Dropbox" tutorials end with "set up a Zap and call it a day." Here's what actually happens.

Zapier's "New Attachment in Gmail" trigger to "Upload File in Dropbox" action works. For one folder. Per Zap.

If you want stripe.com attachments in Dropbox/Receipts/Stripe/, you build a Zap. If you want aws.amazon.com attachments in Dropbox/Receipts/AWS/, you build another. Each Zap matches one sender, lands in one folder.

You have 30 vendors. You'd need 30 Zaps. Zapier's free plan caps at 5 Zaps and 100 tasks/month. Starter is $19.99/mo for 750 tasks. Professional is $49/mo. Every PDF that hits any Zap eats a task.

Plus Zapier has no concept of "file by sender domain into a folder hierarchy." You hard-code each folder. So when a new vendor emails you for the first time, nothing happens. The PDF sits in Gmail unfiled. Same problem as Gmail filters, but with a $50/mo invoice attached.

Power Automate has a Gmail connector (it's Premium tier - $15/user/mo+) and a Dropbox connector. Same custom-expression headache for vendor routing. Same "your flow silently breaks when a token expires."

For more on why duct-tape automation costs more than purpose-built filing, see why we don't OCR your receipts.

Messy automation concept showing Zapier and Power Automate limitations for Gmail to Dropbox filing

How AutoFileEmail handles Gmail + Dropbox

AutoFileEmail's onboarding treats inbox and cloud as independent OAuth flows. Pick Gmail, pick Dropbox, get on with your day.

Two consent screens during onboarding:

Google sign-in window for Gmail. Approve Gmail's read scope.
Dropbox sign-in window. Approve "App folder" access for AutoFileEmail.

Two minutes total. AutoFileEmail polls Gmail every 30 seconds. New attachments file into Dropbox at /Apps/AutoFileEmail/{vendor-domain}/{YYYY}/{MM}/.

That's the whole product on the Gmail + Dropbox combo.

AutoFileEmail onboarding visual showing Gmail and Dropbox connections

Where files actually appear in Dropbox

Open Dropbox on the web or desktop. Look for the Apps folder at the root. Inside it, AutoFileEmail. That's our sandbox.

Inside /Apps/AutoFileEmail/, after a couple weeks of filing:

/Apps/AutoFileEmail/
  amazon.com/
    2026/
      05/
  stripe.com/
    2026/
      04/
        2026-04-14-invoice.pdf
      05/
        2026-05-02-invoice.pdf
  notion.so/
    2026/
      05/
  cursor.sh/
    2026/
      05/
  figma.com/
    2026/
      05/

One folder per registrable sender domain (noreply@billing.stripe.com becomes stripe.com, not billing.stripe.com). Year and month subfolders. Files keep their original names with the email date prefixed so they sort cleanly.

Same structure as Gmail+Drive and Outlook+OneDrive. If you ever switch any leg of the stack, your accountant doesn't have to learn anything new.

Dropbox App folder path visualization with /Apps/AutoFileEmail and vendor folders

App folder mode: Dropbox's privacy sandbox

Dropbox has a permission scope called "App folder," which mirrors Microsoft's Files.ReadWrite.AppFolder for OneDrive. Translated: AutoFileEmail can create, read, update, and delete files inside /Apps/AutoFileEmail/. We cannot see, list, or touch anything else in your Dropbox. The Dropbox API refuses if we try.

For the deep-Dropbox-history user, this matters more than usual. The folders that go back to 2019, the client deliverables, the personal photos that ended up in Dropbox-Camera-Uploads, the legal docs that live in /Documents/Legal/ - all invisible to us. Not "we promise not to look." Literally not in the API surface we have access to.

Compare that to OCR-based receipt tools (Hubdoc, Dext, AutoEntry). They want broad inbox AND broad file access. They scrape, OCR, and store. The trade is "give us your data, we extract structured line items." We don't make that trade. We're not reading your receipts - we're just filing them.

Dropbox App folder sandbox illustration with a lock and cloud icons

Setup, end to end

Click-by-click for Gmail + Dropbox:

Sign up at autofile.email. Pick Google sign-in or magic email.
Click "Connect Gmail." Google consent screen. Approve read access to Gmail.
Click "Connect Dropbox." Dropbox consent screen. Approve App folder access.
Done. AutoFileEmail starts polling within 30 seconds of you finishing onboarding.

If you signed up today, the 30-day historical preview backfill kicks off automatically. April's receipts populate in Dropbox within a few minutes.

If you want a full tax year filed too, the $29 Tax Year Pack covers it. One-time. No subscription. Backfill runs in the background.

Full walkthrough on the Gmail to Dropbox integration page.

Why this beats forwarding to Dropbox's + email

Dropbox used to (and depending on plan still does) offer per-account "mail-to-Dropbox" email addresses. You forward an email there, Dropbox saves the attachments to a specific folder.

Three problems with this for receipts.

First, every receipt becomes a forward. Gmail makes you click 4-5 times per email to forward, or you set up a filter to auto-forward, but Gmail's filter UI doesn't condition on has:attachment reliably so you end up forwarding a lot of non-receipt mail too.

Second, the Dropbox mail-to-folder feature dumps everything into one folder. No vendor routing. No date organization. Same flat-pile problem you started with.

Third, on most current Dropbox plans this feature is deprecated or paywalled behind business tiers. It's not the supported answer anymore.

OAuth + a real polling agent is the supported answer. That's what AutoFileEmail provides.

Diverse creative team at a desk with Gmail and Dropbox icons illustrating the Gmail + Dropbox default for agencies

What about Pro?

Pro is on the waitlist. When it ships ($14.99/mo, 5 inboxes), the relevant Dropbox upgrade will be custom destination folders. Right now we file into /Apps/AutoFileEmail/, locked by the App folder scope. Pro will let you point us at a folder you choose - say, /Receipts/2026/ if that fits your existing Dropbox structure.

For Pro custom destinations, the OAuth scope widens (broader Dropbox access instead of the App folder sandbox). We'll re-prompt for the broader scope at upgrade time. The narrower scope stays in effect until you choose to upgrade.

For now, free tier and /Apps/AutoFileEmail/ is the working pair. It covers the case 90% of receipt-filers actually need.

TL;DR

Gmail + Dropbox is the default stack for agencies, creatives, and long-time Dropbox users with deep file history.
Zapier needs one Zap per vendor (30 Zaps, $50/mo+); Power Automate's Gmail connector is Premium-only and doesn't do vendor routing.
AutoFileEmail's setup: two OAuth screens, files land under /Apps/AutoFileEmail/{vendor}/{YYYY}/{MM}/ in Dropbox, free for one inbox.
Dropbox App folder mode means we cannot see anything else in your Dropbox. Gmail read-only means we can't change anything in your inbox.
The $29 Tax Year Pack covers a full year of retroactive filing if April's receipts need to be in Dropbox by next week.

Free for one inbox + one cloud, no credit card. 30-day historical preview included. Connect Gmail and Dropbox in two minutes - the rest of the year's receipts file themselves.

We don't read your receipts. We just file them.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/save-gmail-attachments-to-dropbox-automatically/gmail-dropbox-attachments-automation-banner-1a258b2e-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Receipts for Taxes: The 3 Folders That Survive an Audit]]></title>
            <link>https://autofile.email/blog/receipts-for-taxes-3-folders-survive-audit</link>
            <guid isPermaLink="false">https://autofile.email/blog/receipts-for-taxes-3-folders-survive-audit</guid>
            <pubDate>Tue, 12 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[An IRS audit asks for one thing: organized records. Here are the 3 folders every solo founder needs, and how to populate the hard one without lifting a finger.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for Receipts for Taxes: The 3 Folders That Survive an Audit

A friend of mine got audited in 2023. Solo consultant, makes around $180k a year, takes the home-office deduction, deducts software subscriptions, the usual.

The IRS letter wasn't dramatic. It asked her to substantiate three categories: software expenses, professional development, and meals. She had 18 months from filing to produce the records.

She handed me her laptop and said "help."

What followed was 11 hours of forensic Gmail archeology. Searching from:adobe.com, from:notion.so, from:linkedin.com (LinkedIn Learning was on the list). Cross-referencing bank statements. Trying to remember which conference she went to in May. Realizing she'd switched email providers in 2022 and half the records were on a domain she'd let lapse.

She got through it. The IRS accepted her records. She owed an extra $340 in interest on a couple of charges she couldn't prove.

Eleven hours of my life I want back.

Here is the system she wishes she'd had. Three folders. That's it.

Table of Contents

What an auditor actually wants
Folder 1: Income
Folder 2: Deductible expenses
Folder 3: Personal-but-taxable events
How the three folders look in practice
A note on bookkeeping software
The bottom line

What an auditor actually wants

Audits are not interrogations. They are paperwork checks. The auditor has a list of line items from your tax return and wants to see the documents that support them.

Per IRS Publication 583, the standard is: "supporting documents that substantiate items reported on your tax return." For most solo founders that means receipts, invoices, canceled checks, mileage logs, and 1099s.

Retention requirements: 3 years from filing date for most returns. 7 years if you under-report income by 25% or more. Forever if you didn't file or filed fraudulent returns. Most people aim for 7 years to be safe.

The auditor doesn't care if your folders are pretty. They care that the documents exist and match the line items.

Illustration of an auditor's wants: organized receipts and a handwritten checklist

Folder 1: Income

What goes in it: 1099-NEC forms from clients. 1099-K forms from payment processors (Stripe, PayPal, Square). W-2 forms if you also had a day job. Interest statements (1099-INT). Dividend statements (1099-DIV). Any other "you got paid this much" form.

For solo founders specifically: Stripe Atlas annual reports, Mercury bank statements showing deposits, PayPal year-end summaries.

What auditors ask for from this folder: every 1099 plus your gross receipts. They cross-check 1099 totals against what's on your Schedule C line 1. If a client filed a 1099 that you didn't report, it shows up here.

Why this folder stays manual: 1099s arrive once a year, in late January or early February. They come from clients via various weird portals (some clients still mail them). Payment processors generate them in their dashboard, not via email attachment. There's no "auto-file" world that helps here. Just have a recurring February calendar reminder: "Download 1099s, drop in Income/2026/."

Volume: 5 to 15 documents a year for most freelancers. Manageable.

Income documents organized for an audit including 1099 forms and payment reports

Folder 2: Deductible expenses

This is the big one. The folder where 95% of audit pain lives. The folder this whole site exists to populate.

What goes in it: every receipt for a business expense you deduct. Software subscriptions (Notion, Adobe, Figma, GitHub, Linear, Cursor, Vercel, AWS, Stripe fees, the whole list). Hardware purchases (a new laptop, a monitor, a desk). Professional development (courses, books, conference tickets). Travel for business. Client meals. Phone and internet (the business-use portion). Co-working space fees. Domain registrations. SaaS, SaaS, SaaS, SaaS.

What auditors ask for from this folder: any line item from Schedule C they want to verify. They might pick "Office expense $4,200" and say "show me." You need every receipt that adds up to $4,200 in office expense for that year.

If you can produce them, the line item stands. If you can't, the auditor disallows it and you owe back tax plus interest plus possibly a 20% accuracy penalty.

This is where AutoFileEmail's domain-based foldering naturally maps. Stripe stuff in stripe.com/. Adobe stuff in adobe.com/. AWS stuff in amazon.com/. When the auditor asks "show me the office software charges," you grab the relevant subfolders and you're done.

The reason this is hard manually: a typical solo founder has 20 to 40 active SaaS subscriptions plus one-off purchases. Each sends 12 invoices a year. You're looking at 250 to 500 receipts a year, in a folder structure your CPA can read.

Doing that by hand on a weekly basis is theoretically possible. Practically, nobody does it. So the receipts live in Gmail, scattered across inboxes and senders, until April when the panic hits. Or worse, until an audit notice 18 months after April.

The fix: connect Gmail and Drive at autofile.email. New receipts auto-file into /AutoFileEmail/{sender-domain}/{YYYY}/{MM}/. Old receipts file via a Backfill Pack. From then on, the folder is populated by default. You don't think about it.

Deductible expenses folder with receipts and SaaS subscriptions visible

Folder 3: Personal-but-taxable events

The forgotten one. Most people don't have a folder for this and lose deductions because of it.

What goes in it: HSA contribution receipts and HSA distribution receipts (you need both to prove the distributions were for qualified medical expenses). Charitable donation receipts above $250 (the IRS requires written acknowledgment from the charity). Medical expenses if you itemize (above 7.5% of AGI threshold). Property tax statements. Mortgage interest statements. Student loan interest statements. State and local tax payments. Any 1098-T form for education.

What auditors ask for from this folder: itemized deduction proof. Most solo founders take the standard deduction now (it's $14,600 single in 2024), so this folder is small. But if you had a high-medical year, or you donated heavily, or you bought a house, suddenly itemizing wins and this folder matters.

This folder also stays manual. HSA receipts come from your HSA provider's portal. Charity acknowledgments come via email but with weird subject lines. Property tax statements come in the mail. The volume is low and the formats are inconsistent enough that automation doesn't pay off.

Recurring December calendar reminder: "Pull HSA records, charity letters, mortgage 1098. Drop in Personal/2026/." Done.

Personal-but-taxable events folder with receipts and donation letters

How the three folders look in practice

Tax Records/
  Income/
    2025/
      1099-NEC-from-client-acme-corp.pdf
      1099-K-from-stripe.pdf
      ...
  Expenses/                          <- AutoFileEmail's job
    stripe.com/
      2025/01/
      2025/02/
      ...
    aws.amazon.com/
      ...
    adobe.com/
      ...
  Personal/
    2025/
      hsa-statement-fidelity.pdf
      donation-letter-american-red-cross.pdf
      property-tax-statement-county.pdf
      ...

Three folders. Two of them stay manual (5 to 20 documents a year, tractable). One of them populates itself as long as your receipts arrive via email (95% of them do, if you're a SaaS-using solo founder).

Three-folder tax-records structure displayed on a computer screen

A note on bookkeeping software

QuickBooks, Wave, Xero will all tell you they can replace this. They can, sort of. They suck attached PDFs into a "documents" tab inside the app. If you ever leave QuickBooks, those documents go with you only if you remember to export them.

A flat folder structure in Drive is platform-neutral. Your CPA can read it. The IRS can accept a USB drive of it. You can copy it to a backup. You can outlive QuickBooks.

If you already have QuickBooks, fine, keep it. But also have the Drive folder. Belt and suspenders.

The bottom line

Three folders: Income, Expenses, Personal.

Income is small and manual. Personal is small and manual. Expenses is huge and automatable.

Spent the whole post on Expenses? Yeah. That's where the pain is. That's where AutoFileEmail lives. Folders 1 and 3 stay manual.

If you're a freelancer or solo founder and want the receipts side handled, see the freelancer setup walkthrough. It's free for one inbox. The full Gmail-to-Drive flow is broken down in the auto-filing guide.

Audits are stressful. Producing the records doesn't have to be.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/receipts-for-taxes-3-folders-survive-audit/receipts-for-taxes-three-folders-banner-804249b5-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Auto-File iCloud Mail Attachments via IMAP]]></title>
            <link>https://autofile.email/blog/auto-file-icloud-mail-attachments-via-imap</link>
            <guid isPermaLink="false">https://autofile.email/blog/auto-file-icloud-mail-attachments-via-imap</guid>
            <pubDate>Wed, 13 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[iCloud Mail has no automation API and Apple isn't shipping one. Here's the working IMAP setup to auto-file @icloud.com receipts by vendor and date.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for AutoFileEmail IMAP workflow with iCloud Mail

If your email is at @icloud.com, @me.com, or @mac.com, you've already discovered the bad news.

Apple has no automation API for iCloud Mail. There are no rules-based attachments-to-iCloud-Drive flows. There's no Shortcut that runs server-side when new mail arrives. There's no Apple-blessed equivalent of Power Automate. Mail.app on macOS has rules, but they only run while Mail.app is open on your laptop, which it usually isn't, and they can't write to iCloud Drive folders the way Drive's own UI can.

Apple has zero plans to add any of this. They've had 15 years to ship "save iCloud Mail attachments to iCloud Drive" and they've never even hinted at it. It's not on the roadmap because there is no public roadmap.

The workaround is older and uglier than any of this: IMAP. Same protocol your phone uses to talk to mail.example.com in 2003. Apple supports it for iCloud Mail, mostly because they have to. AutoFileEmail uses it.

This is the working setup for @icloud.com users.

Table of Contents

What you'll need before you start
Generating an app-specific password at appleid.apple.com
Connecting iCloud Mail to AutoFileEmail
Pick your destination cloud
What the folder structure looks like
The honest IMAP caveat
Outlook (the other IMAP-friendly Apple alternative)
What we don't do (and what Apple doesn't let us do)
Setup recap
TL;DR

What you'll need before you start

Three things:

An iCloud account with Mail enabled.
An app-specific password from Apple. (Two-factor auth required, which it should be already.)
Five minutes.

That's it. No developer account. No paid Apple Business plan. No Mac required - this all works from any browser.

What you'll need before you start: iCloud Mail enabled, app-specific password, five minutes

Generating an app-specific password at appleid.apple.com

Apple won't let third-party apps log into iCloud Mail with your real password. You have to generate a one-off "app-specific password" instead. This is good. It means if AutoFileEmail's password gets compromised somehow, you revoke that one password and your real Apple ID is untouched.

The flow:

Go to appleid.apple.com and sign in.
Sign-In and Security section. Click "App-Specific Passwords."
Click "Generate an app-specific password."
Label it something like AutoFileEmail so you remember why it exists.
Apple shows you a password like abcd-efgh-ijkl-mnop. Copy it. You only see it once.

Keep that tab open. You'll paste the password in AutoFileEmail's IMAP form in the next step.

If you don't have two-factor auth on your Apple ID, Apple won't let you generate an app-specific password. Turn on two-factor first. Same Sign-In and Security page.

Generating an app-specific password at appleid.apple.com for iCloud Mail access

Connecting iCloud Mail to AutoFileEmail

In onboarding, after the cloud step, you'll see "Connect inbox" with three tiles: Gmail, Outlook, IMAP.

Click IMAP.

The form looks like this:

Email address: you@icloud.com (or @me.com / @mac.com)
App password: paste the one you just generated
IMAP host: auto-fills to imap.mail.me.com
IMAP port: auto-fills to 993
TLS: auto-checked

The auto-fill is keyed off the @icloud.com / @me.com / @mac.com part of the address. You don't have to look anything up. Hit "Connect."

AutoFileEmail tries the IMAP login. If the password's right and Apple is happy, the form clears and you see "iCloud Mail connected" with a green checkmark. If something's off (most often a typo in the app password), the form shows the error and you re-paste.

Connecting iCloud Mail to AutoFileEmail via IMAP setup form

Pick your destination cloud

Next step in onboarding: cloud destination. Three tiles: Google Drive, OneDrive, Dropbox.

Drive is most common for @icloud.com users in our data so far. Apple users tend to like Drive's drive.file scope (we only see folders we created, never the rest of your Drive) for the same reason they like Apple's privacy story - narrow scopes, sandboxed access.

OneDrive and Dropbox both support App folder mode, which is even tighter. Files land in /Apps/AutoFileEmail/ and we cannot see, list, or touch anything else in those clouds.

Honest take: a privacy-conscious Apple user filing iCloud Mail receipts via IMAP into Dropbox App folder mode is just about the leakiest-protected workflow you can pick. Apple doesn't trust us with anything beyond the IMAP credentials you generated specifically for us. Dropbox doesn't even let us see anything outside our sandbox. We can read receipts via IMAP, write them to one folder via App folder mode, and that's the end of our access in any direction.

For folder structure deep-dive across clouds, see the Outlook + OneDrive freelancer's filing setup - the same {vendor}/{YYYY}/{MM}/ layout applies regardless of cloud.

What the folder structure looks like

Whichever cloud you pick, the structure is identical:

/Apps/AutoFileEmail/
  amazon.com/
    2026/
      05/
  stripe.com/
    2026/
      04/
        2026-04-14-invoice.pdf
      05/
  apple.com/
    2026/
      05/
        2026-05-09-receipt.pdf
  notion.so/
    2026/
      05/

(Drive omits the /Apps/ prefix; OneDrive and Dropbox include it because of App folder mode.)

One folder per registrable sender domain. noreply@email.apple.com becomes apple.com. do-not-reply@amazon.com becomes amazon.com. The whole point of registrable-domain routing is that two emails from the same vendor land in the same folder no matter which subdomain Apple/Amazon/Stripe used to send it.

Year and month subfolders. Files keep their original names with the email date prefixed.

Folder structure for iCloud Mail filing into AutoFileEmail visualized in pastel Studio Ghibli style

The honest IMAP caveat

iCloud Mail rate-limits IMAP harder than Gmail does. This is real and worth knowing.

A fresh AutoFileEmail account talking to iCloud Mail will, on first connect, want to run the 30-day historical preview backfill. That's roughly 100-300 IDLE / FETCH operations against Apple's IMAP servers, depending on how busy your inbox is. Apple is fine with that pace.

What Apple is not fine with: hammering IMAP with parallel connections. The autofile worker pools connections (one IMAP connection per account, reused across fetches) so we don't trip Apple's per-account rate limits. You won't see a LOGIN throttled error in normal operation.

If you buy a Backfill Pack and run a full 3-year retroactive scan against an iCloud account, the backfill runs slower than it would against Gmail or Outlook. Think hours instead of minutes for a heavy inbox. Apple's IMAP throughput is the bottleneck, not us. You can close the tab and check back later - the job runs server-side regardless.

For comparison: a Gmail backfill of the same scope might finish in 20 minutes. iCloud might take 4 hours. Same eventual outcome, longer wait.

Outlook (the other IMAP-friendly Apple alternative)

Quick note for completeness: some Apple users run an @outlook.com or @hotmail.com Microsoft personal account alongside iCloud, because it's free and the spam filter is decent. If that's your stack, you can connect via Outlook OAuth instead of IMAP - same Mail.Read scope, same setup, less friction than the app-password dance.

For everyone whose primary mail is genuinely iCloud, IMAP is the only path and it works fine.

What we don't do (and what Apple doesn't let us do)

Worth being explicit:

No outbound mail. IMAP read-only login. We can fetch messages and attachments. We cannot send, reply, mark-as-read, or change anything in your inbox. The IMAP commands for those exist; we don't issue them.
No OCR. The PDF in your cloud folder is the same PDF the sender sent. Apple's privacy story means we'd never store parsed receipt data even if we wanted to.
No "scan all your devices" magic. We don't have access to iMessage, Reminders, Notes, Photos, Health, or anything else on your iCloud account. The app-specific password gives us exactly one thing: IMAP read access to Mail.
No on-device processing. Despite the iCloud branding, this all happens server-side, not on your iPhone or Mac. AutoFileEmail's backend talks to Apple's IMAP servers directly. Your devices don't need to be on or even logged in.

If Apple ships a real automation API for iCloud Mail in 2027, we'll add it. Until then, IMAP is the answer.

Setup recap

The full Apple-user setup, click by click:

appleid.apple.com - generate an app-specific password.
Sign up at autofile.email.
Pick your cloud destination (Drive, OneDrive, or Dropbox). OAuth into it.
Click IMAP, paste your @icloud.com address and the app-specific password, hit Connect.
Done. Polling starts in 30 seconds.

The 30-day historical preview backfill kicks off automatically. April's receipts populate in your destination cloud over the next few minutes (or hours, if you've got a heavy iCloud inbox).

If you want a full tax year retroactively filed, the $29 Tax Year Pack covers it. One-time. No subscription. Plan for the backfill to run longer than it would on Gmail because of Apple's IMAP throttling.

Full integration walkthrough at /integrations/imap-drive (the Drive variant; the OneDrive and Dropbox variants follow the same flow).

TL;DR

iCloud Mail has no automation API. Apple has no plans to ship one. IMAP is the only path.
Generate an app-specific password at appleid.apple.com, paste it into AutoFileEmail's IMAP form. Host and port auto-fill from the @icloud.com domain.
Pick a destination cloud (Drive most common; Dropbox or OneDrive most privacy-tight via App folder mode).
Files land in /Apps/AutoFileEmail/{vendor}/{YYYY}/{MM}/ (or /AutoFileEmail/... on Drive). Same structure as Gmail-based setups.
iCloud rate-limits IMAP harder than Gmail; backfill jobs run slower against iCloud. AutoFileEmail's connection pool handles the throttling for you.

Free for one inbox + one cloud. 30-day historical preview included. The leakiest-protected receipt-filing workflow Apple users can pick is iCloud-via-IMAP into Dropbox App folder mode, and it takes five minutes to set up.

We don't read your receipts. We just file them.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/auto-file-icloud-mail-attachments-via-imap/auto-file-icloud-attachments-imap-banner-df8fe745-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Why We Don't OCR Your Receipts (And Why You Shouldn't Want Us To)]]></title>
            <link>https://autofile.email/blog/why-we-dont-ocr-your-receipts</link>
            <guid isPermaLink="false">https://autofile.email/blog/why-we-dont-ocr-your-receipts</guid>
            <pubDate>Fri, 15 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Every receipt app reads your line items to extract data. We don't. Here's why filing is the product, reading is not, and why that keeps the free tier free.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner about privacy-first receipt filing for a calm, modern workspace

Every receipt-management app on the market reads your receipts.

Hubdoc OCRs them. Dext OCRs them. Receipt Bank, AutoEntry, Expensify, Bill.com - all of them parse the line items, extract the totals, and store the structured data on their servers. That's the whole pitch: "we read your receipts so you don't have to."

We don't do that. Not now, not ever.

This article is the why. It's also the longest case I'll make for treating "we don't read your stuff" as a feature, not an absence of a feature.

Table of Contents

Why OCR exists at all
You probably don't keep books
What OCR costs you in privacy
What OCR costs in dollars
What we actually see
"But I want my data extracted"
The bottom line

Why OCR exists at all

OCR on receipts isn't a feature someone invented because it was cool. It's a workflow tool for a specific job: bookkeeping.

A bookkeeper takes a stack of receipts and turns them into a general ledger. That ledger has columns for date, vendor, account, debit, credit, memo. Each receipt becomes one or more journal entries. Every month, those entries get reconciled against bank statements.

This is double-entry accounting. It's a real thing. Real businesses need it. The tools that came up around it - QuickBooks, Xero, Wave - all assume you're keeping books on a monthly cadence and need to reconcile.

OCR shows up because the boring step of "type each receipt's vendor, date, and amount into a journal entry" is hideous data entry. You can pay an accountant $50 an hour to do it, or you can buy software that auto-extracts the fields and lets you review them. OCR is the cheaper-than-a-bookkeeper solution.

Notice what just happened. OCR is a bookkeeper-replacement tool. It only matters if you're keeping books.

Receipts and bookkeeping concept showing OCR exists as a workflow tool in Studio Ghibli style

You probably don't keep books

If you're a solo founder, freelancer, indie hacker, or one-person agency, here is what actually happens at tax time:

You collect a year of receipts. You hand them to a CPA. The CPA categorizes them - what's software, what's office expense, what's professional development. The CPA totals each category. Those totals go on Schedule C. Tax return done.

You did not do double-entry bookkeeping. You did not maintain a ledger. You did not reconcile against bank statements monthly. You did the once-a-year handoff that has been the freelancer norm since freelancing existed.

Your CPA does not need OCR'd data from you. Your CPA needs the PDF. They have their own software (UltraTax, Drake, Lacerte) that has its own data extraction if they want it. What they want from you is organized files.

The freelancer who buys Hubdoc is buying a forklift to move one box. Once a year. The other 364 days the forklift sits in their garage at $35 a month.

Solo founder realizing they probably don't keep books

What OCR costs you in privacy

Let's be specific about what gets sent where.

When Hubdoc or Dext OCRs your receipts, here's the data flow:

The PDF arrives in their cloud (uploaded by you, or fetched from your inbox).
The PDF gets converted to images.
The images go through their OCR engine (often a third-party API like Google Document AI, Amazon Textract, or Microsoft Form Recognizer).
The structured output - line items, vendor, date, total, tax, payment method - gets stored in their database, indexed and searchable.
The original PDF stays in their storage.
You get a dashboard view showing all your receipts as structured rows.

Step 3 is the part most people don't think about. To OCR your receipt, the receipt has to be sent to an OCR engine. That engine, depending on the vendor, may keep the data, train models on it, or ship it to a third-party processor.

What's in a receipt? Vendor name. Date. Amount. Payment method (often the last 4 digits of a card). Sometimes line items so detailed they reveal exactly what services or products you bought. Adobe knows you're on Creative Cloud. Stripe knows your monthly revenue. AWS knows your infra footprint. AWS knows it because they sent the invoice; the receipt-management company knows it because they parsed the invoice.

Multiply by every solo founder with their entire vendor stack on the platform. Now there's a database that can answer "which SaaS tools is the solo-founder market using" with line-item granularity. That database has a price tag. Some company will eventually pay it.

Maybe today's receipt apps are responsible. Maybe they're not. The point is: you have no control once the data is parsed and structured. You can delete the PDF; the extracted data lives separately.

We avoid all of that by not parsing in the first place. Your PDF lands in your Drive. Drive sees it. Google sees it. We see the metadata we need to file it (sender, date, filename) and nothing inside the file.

The full privacy comparison versus competitors lives at /vs/hubdoc if you want the side-by-side.

What OCR costs in dollars

Receipt apps charge what they charge because OCR isn't free.

Modern OCR runs on GPU compute. A single PDF takes a few cents of GPU time to parse, plus storage, plus the indexing step. At scale, with one user uploading 500 receipts a year, that's a few dollars in raw compute per user per year.

Add the OCR vendor markup, the SaaS company's gross margin target (75% plus), and the marketing payback period, and you get pricing like:

Hubdoc: bundled in QuickBooks Online plans at $35+/mo
Dext: $26/mo for Solo, more per document tier
AutoEntry: $12/mo for the smallest plan, then per-document
Expensify: $5/user/mo for the cheap plan, but with submission caps

If you're a solo founder, you're paying $144 to $420 a year so a SaaS company can read every line of every receipt you get. For a once-a-year tax handoff. Where your CPA throws away the OCR data and reads the PDF anyway.

We don't have a GPU bill. We have a "list directory in Drive, save attachment, increment a counter" bill. That bill is small enough that we can offer the free tier free for one inbox forever. Not free for 30 days. Not free until you hit 100 receipts. Free.

The Backfill Packs ($29 Tax Year, $59 3-Year, $99 Lifetime) cover the one-time cost of pulling old emails out of your inbox and filing them. Forward filing - the day-to-day "new email arrives, file it" - stays free.

We don't charge per receipt because we don't pay per receipt. The math composes correctly.

Cost of OCR in dollars represented with receipts and price tags

What we actually see

For full transparency, here is the entire metadata we store per filed document:

Sender email address (to derive the folder name)
Date of the email
Subject line (so the dashboard can show "Stripe payout - April 14")
Original filename of the attachment
A pointer to where the file lives in your Drive
A unique message ID from your mail provider (so we don't double-file)

That's it. We don't store the PDF on our servers. We don't open it to look inside. We move it from your inbox to your Drive, log the move, and stop. The file lives in your Drive, under your account, with the drive.file scope which means we can only see folders we created and never the rest of your Drive.

The detailed access scopes are listed in our privacy policy. The TL;DR: we have less access to your data than your IDE does.

"But I want my data extracted"

Some people legitimately want OCR. If you're a small business with $500k revenue, doing real bookkeeping monthly, with a real bookkeeper, the OCR tools earn their keep. Buy them.

Our user is the one-person shop, the indie hacker, the moonlight freelancer. The person who wants their PDFs in Drive and their CPA happy. The kind of person whose entire tax workflow fits in three folders. That's it. If your needs are bigger, we're not the right tool, and we're never going to add OCR to compete - it would change the privacy contract and the price.

This is also why we'll never build per-email metering. The cost structure that lets us not OCR is the same cost structure that lets us not meter. They're the same decision wearing two hats.

The bottom line

OCR is a bookkeeper-replacement tool. Most solo founders aren't keeping books. So OCR is solving a problem they don't have, at a price they shouldn't pay, with a privacy cost they didn't agree to.

Filing - just moving the PDF to a sensible folder - is the part that's actually missing. We do that. Nothing else. By design.

Try the version that doesn't read your stuff. Free for one inbox at autofile.email. Two-minute setup. Connect Gmail, connect Drive, walk away.

If you want to compare us head-to-head with the OCR-everything tools, see how we stack up against Hubdoc. The tradeoffs are explicit.

We don't read your receipts. We just file them. That's the whole thing.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/why-we-dont-ocr-your-receipts/why-we-dont-ocr-receipts-ghibli-banner-68d2ac70-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Gmail Attachments Are a Tax-Time Landmine (Here's the Fix)]]></title>
            <link>https://autofile.email/blog/gmail-attachments-tax-time-landmine</link>
            <guid isPermaLink="false">https://autofile.email/blog/gmail-attachments-tax-time-landmine</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Gmail search degrades. Filters break. April hits and you can't find half your receipts. Here's why filing as you go beats archeology in March.]]></description>
            <content:encoded><![CDATA[Gmail attachments tax-time landmine with a fix illustration

It's April 6, 2026. You sit down to do your taxes.

You open Gmail. Type has:attachment from:stripe. Hit enter.

47 results.

Some are from noreply@stripe.com. Some are from invoicing@stripe.com. A few are from support@stripe.com from when a card got disputed. They're scattered across 4 years. Some are in your inbox, some in archive, two are in a label called "stripe stuff" you made in 2022 and forgot about.

You click the first result. It's a payout notification. No PDF. Just a link to view in Stripe.

Second result. PDF. You download. It saves as invoice.pdf to Downloads. Same filename as everything else.

Twenty-five clicks later, you have a folder of invoice.pdf files numbered 1 through 25, no idea which is which. You haven't even started on AWS.

This is the Gmail tax-time landmine. Most people walk into it once a year, every year, and tell themselves they'll fix it next year.

Here's what's actually broken, and how to fix it without a heroic April effort.

Table of Contents

Gmail isn't a filing system
Why Gmail search degrades over time
The 30-minutes-per-vendor cost
The hidden cost: missed deductions
The fix is "file as you go"
What about the 3 years already in your inbox?
What forward filing looks like in practice
What about other tools?
TL;DR

Gmail isn't a filing system

Gmail is a search system. The two are different.

A filing system organizes documents by structure. Folders, names, hierarchies. You navigate to where the document lives. The structure tells you what's there.

A search system finds documents by query. You type something, you get results. There's no structure. The query has to do all the work.

Gmail is built around search, not structure. Labels are flat tags, not folders. Threads collapse subjects into single nodes. Archive is a black hole that "search will find later." This works great for "where's that email from Mom about Thanksgiving" and terribly for "give me every business expense from January 2024 in chronological order."

The IRS does not query Gmail. The IRS queries you. You need structure, and Gmail is the wrong tool to provide it.

Illustration of Gmail labeling vs. traditional filing system in a cozy home office

Why Gmail search degrades over time

The trick people use to make Gmail work as a filing system is search. "I'll just search when I need it."

This works for a year. Maybe two. Then it breaks.

Reasons it breaks:

Senders change addresses. Stripe used to send from notifications@stripe.com, then noreply@stripe.com, then billing@stripe.com. Each migration leaves a gap in your search. from:stripe catches them all if you're lucky. If a vendor used a third-party email service like Postmark or SendGrid, the from-address may not even contain the vendor name.

Your filters age out. That filter you set in 2022 to label all Stripe emails? It used the old domain. Half your 2023 Stripe receipts didn't get the label. You won't know until you look in 2026.

Threading hides things. Gmail collapses replies into threads. If you replied to a Stripe support thread in 2023, the original invoice attached to that thread becomes a child message inside a longer conversation. has:attachment finds it, but the attachment count looks weird and you might miss it visually.

Spam filters are aggressive. Some of your invoices ended up in Spam. Spam auto-deletes after 30 days. Those receipts are gone. There's no recovery.

Archive is a graveyard. You archived 2,000 emails over two years. Half of them have receipts. Search finds them only if you remember the right search terms.

The system works, until you ask it to produce a complete record. Then it doesn't.

Gmail search efficiency degrades over time with scattered invoices

The 30-minutes-per-vendor cost

Solo founders typically have 20 to 40 active SaaS subscriptions plus one-off vendors. At tax time, the manual extraction process per vendor is roughly:

Search the sender. 1 minute.
Skim 12 to 50 results. 5 minutes.
Download the PDFs that exist. 10 minutes.
Rename them so you can tell them apart. 8 minutes.
Drop into the right folder. 3 minutes.
Realize three are missing, search variants of the sender name. 5 minutes.

Call it 30 minutes per vendor. 25 vendors equals 12.5 hours.

12 hours of hand work in early April for what is, fundamentally, a copy-paste job. If you have a CPA you're already paying, that 12 hours is also money: most CPAs will charge $50 to $150 an hour to do this for you, if they're even willing.

Time cost per vendor shown with clocks and vendor icons

The hidden cost: missed deductions

Here's the part that hurts more than the time.

When manual extraction is painful, people give up partway. The 23rd vendor doesn't get searched. The Adobe receipts from October to December don't get pulled. The conference ticket from March is "in there somewhere."

You skip the receipts you can't find. You skip the deductions you can't substantiate. You over-pay tax.

Average solo founder probably leaves $300 to $1,500 on the table this way every year. Not from missing income, just from missing deductions because the receipts weren't findable.

The IRS isn't going to call you about it. Nobody is. The money just stays with the IRS instead of in your bank account, and you don't notice because you never had it.

This is the actual cost of treating Gmail as a filing system. Not the time. The skipped deductions.

Missed tax deductions due to unfiled receipts with tax form

The fix is "file as you go"

Every accountant I've talked to says the same thing: keep your records as you receive them, not all at once at year-end.

Sounds obvious. Almost nobody does it.

The reason is that filing as you go costs you small bits of attention every week. Open the email. Save the attachment. Switch apps. Drag to folder. It's 90 seconds, but it's 90 seconds you have to do hundreds of times. Over a year, the total is the same as April archeology, but spread out. People dislike that math intuitively even though it's correct.

The way to make "file as you go" actually work is to have something else do it. Not a habit, not a Sunday batch, not a calendar reminder. A background process.

That's what AutoFileEmail is. New email arrives. PDF inside. Attachment lands in /AutoFileEmail/{sender-domain}/{YYYY}/{MM}/. You don't see it happen. You don't approve it. It just runs.

The full mechanics of the auto-filing flow are walked through here if you want the technical detail.

Auto filing receipts into Google Drive as a background process

What about the 3 years already in your inbox?

This is the second half of the problem. Even if you set up forward filing today, you still have the entire history sitting in Gmail unfiled.

Backfill Packs handle this. One-time purchase, you pick a date range, the system pulls every attachment from that range and files it the same way forward filing does.

Pricing is simple:

$29 Tax Year Pack: one tax year, backwards from today
$59 3-Year Pack: three years
$99 Lifetime Pack: everything in your Gmail history (capped at 50,000 emails)

No subscription. No per-email fees. No refunds (be sure of the date range; the credit is consumed when the job runs). Backfill credits never expire.

If you're a freelancer doing your first organized tax year, the 3-Year Pack usually pays for itself in recovered deductions. The full freelancer playbook is at /solutions/freelancers.

What forward filing looks like in practice

Day 1: you sign up at autofile.email. Connect Gmail (read-only). Connect Drive (drive.file scope, we can only see folders we created). 30-day historical preview runs automatically so you see results immediately.

Day 30: you check Drive. There's a /AutoFileEmail/ folder. Inside it, one folder per vendor that emailed you a receipt this month. Inside each, a 2026/05/ folder with PDFs.

Day 365: you check Drive in April 2027. Twelve months of folders. Every receipt where it should be. You hand the link to your CPA.

The work you did was the 2-minute setup on Day 1. That's it.

What about other tools?

Zapier can do parts of this. So can IFTTT. So can Apps Script if you write code.

The full breakdown of why those don't actually solve the problem is in the Gmail-to-Drive guide. Short version: they file to one folder per setup, not by sender domain, so you'd need 30 separate setups for 30 vendors and the cost adds up.

AutoFileEmail does the per-sender-domain part natively because that's the whole product. There's nothing to configure per vendor; new vendors get folders automatically the first time they email you.

The other direction people go is a receipt-scanning platform: Dext, AutoEntry, Hubdoc, Expensify. Those solve a different problem. They read the receipt and push line items into accounting software, which is worth paying for if somebody is actually reconciling your books, and is money set on fire if nobody is. We went through the alternatives and who each one is really for, and priced up Dext against AutoEntry for anyone choosing between those two specifically.

Worth knowing before you buy any of them: the accountants we asked said they want folders, not extracted data, and the IRS bar is lower than most people assume — here's what a receipt actually has to show.

TL;DR

Gmail is a search tool. You are using it as a filing tool. It will betray you in April.

The fix is filing receipts as they arrive, not all at once. Do that without spending 90 seconds per email by letting a background process handle it.

Connect Gmail and Drive in 2 minutes. Free for one inbox. The receipts file themselves.

April 2027 you will thank you.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/gmail-attachments-tax-time-landmine/gmail-attachments-tax-landmine-banner-c8251db8-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Auto-File PDFs From Email Into Drive Folders]]></title>
            <link>https://autofile.email/blog/auto-file-pdfs-email-drive-folders</link>
            <guid isPermaLink="false">https://autofile.email/blog/auto-file-pdfs-email-drive-folders</guid>
            <pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Manual save-and-drag for every email PDF doesn't scale. Here's how Gmail filters, Zapier, and Power Automate stack up against domain-based auto-filing.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for auto-filing PDFs from email into Drive folders

Here's the workflow you do today, probably without thinking about it:

Email arrives with a PDF attached.
You open the email.
You click the attachment thumbnail.
The PDF previews. You click "download" or right-click "save as."
You alt-tab to Drive.
You navigate into Drive/Receipts/2026/Stripe/.
You drag the PDF in.
You realize it's named invoice.pdf like every other Stripe invoice.
You rename it to 2026-04-stripe-payout.pdf.
You go back to Gmail. Repeat for the next email.

Multiply by every receipt you get. That's the manual flow.

Most attempts to automate it solve about 60% of the problem and stop. This post walks through what actually works, what doesn't, and why.

Table of Contents

What you actually want
Gmail filters: nope
"Save to Drive" button: half a solution
Zapier: works for one folder at a time
Domain-based auto-filing: the missing approach
Setup walkthrough
When the other tools are still right
The bottom line

What you actually want

Before evaluating tools, here's the spec the tool needs to satisfy:

New email with PDF attachment arrives.
PDF is saved to Drive (not stored elsewhere).
The folder is determined by who sent the email, not by hand.
The folder structure scales: a new vendor doesn't require new setup.
Filename includes enough metadata to disambiguate (date, sender) since most senders use generic filenames like invoice.pdf.

That's the spec. Let's see what hits it.

Gmail filters cannot auto-file attachments into Drive folders

Gmail filters: nope

Gmail filters can label, archive, mark as read, forward, and skip the inbox. They cannot:

Download attachments
Save attachments to Drive
Create Drive folders

This is documented behavior, not a missing feature. Filters operate on email metadata and don't have side effects outside Gmail.

You can use a filter as input to other tools (Zapier triggers can listen for a label), but the filing step has to happen elsewhere.

Verdict: filters are a useful prefilter. Not a filing solution.

(blank line)
Gmail 'Save to Drive' button limitations illustration

"Save to Drive" button: half a solution

Hover over an attachment in Gmail. A Drive icon appears. Click it. The PDF saves to your Drive root.

Two problems:

It's manual. You have to open every email and click the button. Solves zero of the workflow.
It saves to My Drive by default. No folder structure. No sender-based organization. Your Drive becomes a swamp of invoice.pdf, invoice (1).pdf, invoice (2).pdf.

You can move them around manually after the fact. But then you're sorting files by hand, which is the original problem with extra steps.

Verdict: works for one-off "I want this PDF in Drive right now." Useless as a system.

(blank line)
Zapier-style automation with multiple zaps filing into folders

Zapier: works for one folder at a time

Zapier has a Gmail trigger called "New Attachment." It fires when an email with an attachment arrives. You can chain it to a Drive action called "Upload File" that saves the attachment to a Drive folder.

The catch: each Zap targets one folder.

If you want Stripe attachments in Drive/Receipts/Stripe/, you build a Zap with the trigger filter set to from:stripe.com and the action target set to that folder.

If you want AWS attachments in Drive/Receipts/AWS/, you build a second Zap with from:amazon.com and the AWS folder.

If you want Adobe attachments in Drive/Receipts/Adobe/, third Zap.

You see where this goes. A solo founder with 25 vendors needs 25 Zaps. Zapier's free plan caps at 5 Zaps and 100 tasks a month. The Starter plan ($19.99/mo) caps at 20 Zaps. The Professional plan ($49/mo) is unlimited Zaps but charges per task.

Each PDF eats a task. 200 PDFs a year is 200 tasks. At Professional pricing that's a few cents per file just in tooling cost, before you account for your time setting up 25 separate Zaps.

There's also no built-in concept of "the folder name should be the sender domain." You hardcode each folder. New vendors that aren't in your Zap library don't get filed. You only find out months later when you go looking.

Verdict: works if you have a small, stable vendor list and don't mind paying $20 to $49 a month. Doesn't work for the actual freelancer use case.

(blank line)
Domain-based auto-filing concept mapping sender domains to Drive folders

Domain-based auto-filing: the missing approach

The thing none of the above tools do natively: file by sender domain, no per-vendor configuration.

The approach is straightforward:

New email arrives with attachment.
Pull the sender email. noreply@billing.stripe.com.
Extract the registrable domain (eTLD+1). Result: stripe.com.
Build the path: /AutoFileEmail/stripe.com/2026/04/.
Save the attachment. Filename gets prefixed with the email date: 2026-04-14-invoice.pdf.

The eTLD+1 step is the trick. It collapses subdomains so noreply@billing.stripe.com, support@stripe.com, and invoicing@stripe.com all map to the same stripe.com folder. Same for noreply@aws.amazon.com and bills@aws.amazon.com: both go to amazon.com.

We use the tldts library to do the domain extraction. It handles edge cases like .co.uk and .com.au correctly. Without that, you'd map vendor.co.uk to co.uk (wrong) instead of vendor.co.uk (right).

Concrete examples of what the filing engine does:

| From address | Folder |
|---|---|
| noreply@billing.stripe.com | /AutoFileEmail/stripe.com/ |
| bills@aws.amazon.com | /AutoFileEmail/amazon.com/ |
| team@notion.so | /AutoFileEmail/notion.so/ |
| receipts@figma.com | /AutoFileEmail/figma.com/ |
| noreply@adobe.com | /AutoFileEmail/adobe.com/ |
| support@cursor.sh | /AutoFileEmail/cursor.sh/ |
| info@noreply.github.com | /AutoFileEmail/github.com/ |

No vendor list to maintain. New senders get folders automatically.

This is what AutoFileEmail does. It's not a generic automation builder; it's a single-purpose filing engine. The integration list is at /integrations and the Gmail-to-Drive flow specifically is at /integrations/gmail-drive.

(blank line)
Domain-based auto-filing concept mapping sender domains to Drive folders

Setup walkthrough

Sign up at autofile.email with Google.
Approve Drive access (drive.file scope, the narrowest one Google offers).
Approve Gmail access (read-only).
Done. New attachments file within 30 seconds of arriving.

A 30-day historical preview runs on signup so you see real results immediately. If you want older history filed too, Backfill Packs start at $29 for one tax year.

The full Gmail-to-Drive setup walkthrough including troubleshooting is in the auto-filing guide.

When the other tools are still right

Zapier, IFTTT, Apps Script, Power Automate: they're the right call when:

You have one specific filing rule and won't add more.
You need cross-app logic beyond just Drive (post to Slack, log to a sheet, ping an API).
You enjoy building automation as a hobby.

For "I just want my email PDFs in sensibly-organized Drive folders without thinking about it," AutoFileEmail is the path with the lowest setup time and zero ongoing maintenance.

The bottom line

Manual filing: works, until you have a real vendor count.

Gmail filters and "Save to Drive" button: don't actually solve the filing-to-structure problem.

Zapier, IFTTT, Power Automate: per-vendor configuration, monthly fees.

Apps Script: free if you can code and don't mind maintenance.

Domain-based auto-filing: configure once, every new vendor self-files. Free for one inbox at autofile.email. Connect in 30 seconds.

Try it. Worst case you save 12 hours next April.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/auto-file-pdfs-email-drive-folders/auto-file-pdfs-from-email-into-drive-ghibli-banner-7b477179-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Why Hubdoc, Receipt Bank, and Dext Are Overkill For Solo Founders]]></title>
            <link>https://autofile.email/blog/hubdoc-receipt-bank-dext-overkill-solo-founders</link>
            <guid isPermaLink="false">https://autofile.email/blog/hubdoc-receipt-bank-dext-overkill-solo-founders</guid>
            <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Hubdoc and Dext were built for accounting firms juggling 50 clients, not for you. Here's why a solo founder doesn't need OCR, just a folder.]]></description>
            <content:encoded><![CDATA[Solo founder overwhelmed by receipts and pricing realities

You are a solo founder. Your "books" are a Stripe dashboard, a business checking account, and a folder of PDFs your CPA will see exactly once, in March.

You read a thread on r/Entrepreneur. Someone says "use Hubdoc." Someone else says "Dext is better." A third person says "Receipt Bank, but it's called Dext now."

You sign up. You hit a pricing page that says $25-50 a month. You see the integrations: Xero, QuickBooks Online, Sage. You don't use any of those. You use a spreadsheet.

You start to feel like you walked into the wrong room.

You did. These tools are great. They were just not built for you.

Table of Contents

Who these tools were actually built for
The pricing nobody talks about
What that money buys you
How a solo founder's books actually work
What a CPA actually wants
The cheaper option
When you actually do need Hubdoc or Dext
When you don't
What the trade actually costs you
The bottom line

Who these tools were actually built for

Hubdoc, Dext (formerly Receipt Bank), and AutoEntry were designed for accounting firms. Not for the people whose receipts they file.

A bookkeeper at a small accounting firm has 30 to 80 clients. Each client has a few hundred receipts a month. The bookkeeper's day job is to take those receipts, OCR them, push the line items into Xero or QuickBooks, reconcile against bank feeds, and produce financial statements.

Hubdoc and Dext exist to compress that workflow. They OCR every receipt. They auto-publish into accounting software. They handle multi-client logins. They ship line-item data so the bookkeeper does not have to retype anything.

That is a real product solving a real problem. For a bookkeeper running 50 client books, the math is obvious: $30/mo per client buys back several hours of typing. Net positive every month.

You are not a bookkeeper running 50 client books. You are a person who needs to hand a folder of PDFs to a CPA once a year.

Bookkeeper with many clients contrasted with a solo founder at a tidy desk

The pricing nobody talks about

Let's do the actual numbers. Public pricing, May 2026:

Hubdoc: $12/mo as a standalone tool, but its real distribution is bundled inside QuickBooks Online ($30-65/mo) and Xero ($15-78/mo). If you don't already pay for those, the bundle is the price.
Dext (Receipt Bank): $25/mo solo plan, capped at a low document count. $50/mo for the next tier. Add-ons for line-item extraction.
AutoEntry: $12/mo for 50 credits, $23/mo for 100. Each receipt eats a credit.

Now stack the accounting software you'll inevitably end up paying for to make the integration useful:

QuickBooks Online Simple Start: $30/mo
Xero Starter: $15/mo (capped at 20 invoices)

So a "Hubdoc setup" is realistically $40-95/mo. That is $480-1,140 a year. Before you've filed a single receipt.

Pricing for Hubdoc, Dext, and AutoEntry

What that money buys you

OCR. Line-item extraction. Auto-publish into a chart of accounts. Bank feed matching. Multi-user permissions. Audit trails.

Useful features. For an accounting firm. For you, a person whose books are 99% Stripe payouts in and SaaS subscriptions out, most of these features are a tax on a job you don't have.

You don't reconcile bank feeds weekly. You don't have a chart of accounts. You don't categorize transactions monthly because there is nobody but you to read the categorization.

You are paying $40 a month for software that solves the bookkeeper's problem, when your actual problem is "I have 200 invoice PDFs in Gmail and I need them in a folder."

Receipts vs Drive folder illustrating OCR value

How a solo founder's books actually work

Here is the honest workflow for most one-person operations:

Income is whatever your Stripe dashboard says.
Expenses are receipts emailed to you by 15-30 SaaS vendors.
In March, you forward everything to a CPA.
The CPA does the categorizing.
You sign and pay.

The "books" exist for two days a year. The other 363 days, you need the receipts to exist somewhere you can find them in five minutes.

That is a filing problem. Not an OCR problem. Not a categorization problem. Not a bank-feed problem.

If you write off $8,000-15,000 of expenses in a year (typical solo founder range), the value of OCR is roughly zero. Your CPA charges $300-800 to do your taxes. They are not going to charge you less because Hubdoc fed them pre-categorized line items. They are going to skim the folder, ask you three questions, and file.

Workflow of a solo founder's books: Stripe, Gmail receipts, CPA in March

What a CPA actually wants

I've asked a few. The answer is consistent. They want a Drive folder. Organized by year, then by vendor, then by month. PDFs with sensible names.

That's it.

The CPA does not want your Hubdoc dashboard. They have their own software. What they want is the raw documents, organized in a way they can scan in 20 minutes. The folder structure your accountant actually wants is shockingly boring. No OCR involved.

When the IRS comes calling - and the audit rate for solo founders writing off >$25K is non-trivial - what they want is also boring. Original PDF, original sender, date received. The IRS does not care about your line-item extraction. They care that the receipt is genuine and matches the deduction.

CPA wants a well-organized Drive folder of receipts

The cheaper option

We built AutoFileEmail because the gap between "Gmail filters" and Hubdoc is enormous and we kept falling into it.

The shape: connect Gmail, connect Drive, every PDF that lands in your inbox files itself into /AutoFileEmail/{vendor}/{YYYY}/{MM}/. No OCR. No accounting integration. No chart of accounts. No line items.

It is just a filer.

Cost: free for one inbox, forever. Backfill the last few years for $29-99 one-time, depending on how far back you go. That's it. There is no monthly bill.

What you give up: line-item extraction. Auto-publish to Xero. Bank feed reconciliation. Things you don't do today and weren't going to start.

What you get: a Drive folder you can hand to a CPA. The same Drive folder you'd build manually if you had three weekends to spare.

When you actually do need Hubdoc or Dext

Honest take. Don't replace these tools with us if:

You run an accounting firm. Hubdoc/Dext are correct. Stay there.
You manage books for 5+ businesses. Same.
You already pay for QuickBooks Online or Xero, you're disciplined about reconciling, and you genuinely want OCR in your workflow. The marginal cost is small for you and the integration is nice.
You have 1,000+ receipts a month and need bulk processing.

If any of those describe you, this article is not for you and you should keep using what works.

When you don't

Replace them with a filer (or with us specifically) if:

You're solo. Or a 2-3 person team without a dedicated bookkeeper.
Your "accounting software" is a spreadsheet plus a CPA in March.
You have under ~500 receipts a year, mostly SaaS subscriptions and SaaS payouts.
You don't open Hubdoc weekly. You log in twice a year, panic, and click around.
Your CPA gets a Drive folder, not a QuickBooks login.

That last bullet is the litmus test. If your CPA asks for a Drive folder, you don't need Hubdoc. You need the folder.

Where the money buys you?

What the trade actually costs you

The honest cost of switching from Hubdoc/Dext to a filer is:

No more line-item OCR. (You weren't using it.)
No more auto-categorization. (Your CPA does this.)
No more "the dashboard says I spent $487 on software last month" widget. (Your bank feed already shows that.)
You go from a recurring subscription down to $0, or a one-time $29-99 if you want the back years filed.

To put real numbers on it: Dext Business lists at $302.50 billed annually, and AutoEntry starts at $13 a month for 50 credits. Hubdoc needs a Xero plan underneath it. (Prices read from each vendor's pricing page on 23 September 2026.) So the saving is somewhere between a couple hundred and several hundred a year, depending which one you are on. Not life-changing. Not nothing either. Roughly a CPA's hourly rate.

There's also a privacy angle worth knowing: by not OCRing, we're not building a database of your line items. Why we don't OCR your receipts is a longer story for another day.

The bottom line

Hubdoc, Dext, and Receipt Bank are well-built tools solving the bookkeeper's problem. The bookkeeper's problem is not your problem.

Your problem is: PDFs land in Gmail, they need to live in Drive, organized so a CPA can find them. That is a filer's job, not an accounting platform's job.

If you are weighing up the specific tools, there is a full list of Dext alternatives, a Dext vs AutoEntry breakdown with current pricing, and a side-by-side against Dext. And if the actual pain is that Gmail loses your receipts, that is the tax-time landmine.

If you're a freelancer or solo founder, the tax-time workflow is built around exactly this pattern. Connect Gmail in 30 seconds. Free for one inbox. No per-receipt fees. No monthly bill.

Try it. If you decide later you do want OCR and a chart of accounts, Hubdoc will still be there. They have lots of customers. None of them are you.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/hubdoc-receipt-bank-dext-overkill-solo-founders/why-hubdoc-overkill-solo-founders-banner-efb56a97-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Receipt Apps and What They Do With Your Data, Ranked]]></title>
            <link>https://autofile.email/blog/receipt-apps-data-privacy-ranked</link>
            <guid isPermaLink="false">https://autofile.email/blog/receipt-apps-data-privacy-ranked</guid>
            <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[What happens to your receipts after you upload them? A privacy ranking of Hubdoc, Dext, Expensify, Wave, FreshBooks, Bench, Intuit, and AutoFileEmail.]]></description>
            <content:encoded><![CDATA[Receipt Apps and What They Do With Your Data, Ranked

When you upload a receipt to a "receipt app," what actually happens to it?

Most people don't ask. The receipt goes in, a row in a dashboard comes out, and we trust the rest.

But the receipt is not nothing. It has a vendor name, an amount, a date. Often a customer email. Sometimes a home address. A line-item breakdown of what you bought. For B2C businesses, a buyer's identity. For B2B, a corporate spend pattern that's worth real money to anyone who can aggregate enough of them.

So: what do these apps do with that data?

I read the privacy policies. Here's the ranking, scored on four axes that actually matter.

Table of Contents

The four axes
Hubdoc
Dext (formerly Receipt Bank)
Expensify
Wave
FreshBooks
Bench
QuickBooks Receipt Capture (Intuit)
Shoeboxed
AutoFileEmail (us)
What this means in practice
How to actually pick
The bottom line
Sources

The four axes

The grading system, applied evenly to every app in this list:

Does it OCR or extract content? If yes, the app has a database of line items, vendor names, and amounts that's separate from the original PDF.
Does it use your data to train models? Buried in some privacy policies, called out in others. Material whether you agreed or not.
Where is it hosted? US, EU, or other. Affects who can subpoena it.
Can you fully delete? Some apps "soft-delete." Some retain copies for "fraud prevention" or "legal" purposes for years after you cancel.

I'm working from the apps' own published privacy policies and DPAs as of May 2026. Links at the bottom. If they change theirs, this article will go stale - read the source if accuracy matters to you for compliance reasons.

Hubdoc

OCR? Yes, by design. The product is OCR-into-your-accounting-software.

Training? Hubdoc's privacy policy doesn't explicitly grant training rights, but it allows "use to improve the service." Vague. Owned by Xero (acquired 2018), so any practice flows into Xero's data handling.

Hosted? AWS US-East and EU regions, depending on your account.

Fully delete? Yes, on cancellation, with the standard "we retain backups for X days" caveat. Reasonable.

Score: 4/10. The OCR-by-default architecture means even if you delete, copies of your receipt content lived in their indexing pipeline. Not a privacy disaster, but not the lightest footprint either. (Longer breakdown of the OCR-vs-filing trade in our vs Hubdoc page.)

Hubdoc OCR-by-design privacy footprint

Dext (formerly Receipt Bank)

OCR? Yes. Their pitch is line-item extraction.

Training? Their privacy policy mentions using "anonymized" data to improve their extraction models. That's training, just phrased politely.

Hosted? UK + EU regions primarily, US for North American customers. ISO 27001 certified.

Fully delete? Yes, but they retain "summary metadata" for 7 years for tax-record integrity. Reasonable, but worth knowing.

Score: 5/10. The model-training disclosure is more honest than most. The trade is that your receipt content has, in some abstracted form, helped train their OCR. If your buyer-side details show up in those receipts, that detail traveled.

Dext OCR and model training disclosure visual

Expensify

OCR? Yes, their "SmartScan" feature.

Training? Their policy permits use of customer data to improve services, including ML. They've been public about training their OCR on customer receipts.

Hosted? AWS US-East primarily.

Fully delete? Account deletion exists. Receipt data retention policies are less clear-cut. Their public policies have been revised multiple times in the last 24 months.

Score: 4/10. SmartScan is genuinely good at what it does. The trade is the same: your receipt content fed the model.

Expensify privacy policy mentions machine learning training

Wave

OCR? Yes, for receipt scanning. They added it after H\&R Block acquired Wave in 2019.

Training? Privacy policy permits service improvement use. Not explicit about ML training.

Hosted? US (AWS).

Fully delete? Yes, but parent-company data sharing with H\&R Block is permitted in their policy. So if you use Wave and an H\&R Block service, your data may flow between them.

Score: 5/10. The H\&R Block parent-company link is the fingerprint here. If you're indifferent to that flow, it's fine. If you're a consumer who already files with someone else, the parent-company sharing is non-zero.

Wave data sharing with H\&R Block explained

FreshBooks

OCR? Optional via add-ons. Their core product is invoicing, not receipt OCR.

Training? Policy is conservative. No explicit ML training language.

Hosted? US and Canada.

Fully delete? Yes. Reasonable retention for tax-record purposes.

Score: 7/10. Lighter footprint because OCR isn't the core product. If you use FreshBooks for invoicing and just upload receipts as attachments, the footprint stays small.

FreshBooks OCR is optional; core invoicing focus

Bench

OCR? Yes, but the bigger story is Bench is a bookkeeping service - actual humans plus automation. So your receipts are read by both software and people.

Training? Their policy permits aggregated and anonymized data use.

Hosted? US.

Fully delete? On cancellation, yes. Retention follows the bookkeeping-records standard (7 years for IRS purposes).

Score: 4/10. Not because Bench is sketchy - they're a legit firm - but because the data lives in more places (their software, their bookkeepers' workflows, their accounting backend). More copies, more surface area.

QuickBooks Receipt Capture (Intuit)

OCR? Yes.

Training? Intuit's privacy policy is unusually frank: they use customer data, including financial data, across their product family (QuickBooks, TurboTax, Mint legacy, Credit Karma). In 2024 they were called out by the FTC over disclosure practices in marketing.

Hosted? US (their own data centers and AWS).

Fully delete? Account deletion exists, but the data-sharing across the Intuit family is the part that catches people off-guard.

Score: 3/10. Powerful product, big company, broad data-sharing across an ecosystem most people don't realize they joined. Not the worst, but the largest single-vendor data footprint on this list.

Shoeboxed

OCR? Yes. Plus a physical mail-in option (you mail them shoeboxes, they scan).

Training? Permitted for service improvement. Not explicit about ML.

Hosted? US.

Fully delete? Yes. Physical receipts are shredded on a schedule.

Score: 5/10. The physical mail option adds a chain-of-custody question. The digital service is comparable to the others in this list.

AutoFileEmail (us)

I'll be specific about what we do, because we want this article to age honestly.

OCR? No. We never read the contents of your attachments. The PDF that lands in your Drive folder is bit-for-bit the PDF Stripe (or whoever) sent you. There is no extraction pipeline. You can verify this: open any filed PDF, compare its hash to the hash of the original email attachment. They match.

Training? No. We can't train on something we can't read. We don't run inference on your file contents. The only metadata we look at is the email headers we need to file: sender, date, message ID, subject (for the filename). Those live in our database for one reason - dedup, so we don't double-file the same email if it's seen twice.

Hosted? Cloudflare Workers (compute) plus Supabase (Postgres on AWS US-East). Your filed receipts live in your Google Drive, not on our servers.

Fully delete? Yes, and the deletion is small because there isn't much to delete. Email metadata, OAuth tokens (encrypted), and your billing record. The receipts themselves stay in your Drive, where they always were. Cancel us tomorrow and your folder structure is intact - we just stop adding to it.

Score: 9/10. Not 10, because we're a startup and you should never give anyone full marks. We could screw up tomorrow. The architecture is the cleanest on this list because we deliberately built it to have nothing to leak. More on the why we don't OCR reasoning if you want the long version.

What this means in practice

If you're a B2C operator and your customer emails appear on receipts, the OCR-heavy apps in this list have, at minimum, indexed your customers' personal details. That may or may not bother you, but you should know.

If you're a solo founder filing your own receipts and they're mostly SaaS subscriptions (no PII beyond your own), the privacy gap between the apps is smaller. It still exists, but the stakes are lower.

If you're in the EU or you have EU customers, GDPR makes some of this an actual compliance question rather than a vibes question. We have a GDPR-for-one-person-businesses primer if that's where you're heading.

How to actually pick

Three questions, in order:

Do I need OCR? If yes, accept the privacy footprint and pick the OCR app whose policy you can live with. Dext and FreshBooks are the more conservative options.
Does my CPA need a folder, or a dashboard? If a folder, you don't need OCR at all. A filer is enough.
Am I prepared to delete and verify deletion? If yes, the OCR apps are fine. If you want "no copies of receipt content anywhere but in my own Drive," you need a non-OCR option.

For most solo founders, the answer to #2 is "a folder," and the rest of the questions become moot.

The bottom line

OCR is a feature most receipt apps were forced to add because their bookkeeper-firm customers demanded it. It is not a feature most solo founders need.

The privacy cost of OCR is real but manageable. The dollar cost (covered in the Hubdoc/Dext piece) is the bigger annoyance for most one-person businesses.

If you want a filer that does the boring job and nothing else, AutoFileEmail is free for one inbox. Files land in your Drive. We never read them. Cancel and there's nothing to delete because we never had your receipts in the first place.

Or pick a different one. But pick deliberately. The privacy policy for the receipt app you use is worth the 10 minutes it takes to read.

Sources

Hubdoc privacy policy: hubdoc.com/privacy
Dext data processing addendum: dext.com/legal
Expensify privacy policy: use.expensify.com/privacy
Wave terms and privacy: waveapps.com/legal
FreshBooks privacy: freshbooks.com/policies
Bench privacy: bench.co/privacy
Intuit privacy: intuit.com/privacy
Shoeboxed privacy: shoeboxed.com/privacy

(All accessed May 2026. Privacy policies change. Verify before relying on this article for compliance work.)
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/receipt-apps-data-privacy-ranked/receipt-apps-data-ranked-banner-c3763538-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[The One Drive Folder Structure Your Accountant Actually Wants]]></title>
            <link>https://autofile.email/blog/drive-folder-structure-accountant-wants</link>
            <guid isPermaLink="false">https://autofile.email/blog/drive-folder-structure-accountant-wants</guid>
            <pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Your CPA doesn't want OCR or dashboards. They want a folder. Here's the exact year/vendor/month structure that survives tax season and an audit.]]></description>
            <content:encoded><![CDATA[Organized drive folders for receipts by year, vendor, and month with Studio Ghibli-inspired warm vibe

It's March. Your accountant emails: "Send me your receipts."

You open Drive. You have a folder called Receipts. Inside it, 847 PDFs. Names like invoice.pdf, invoice (1).pdf, invoice-2024-final-FINAL.pdf. Some have dates. Most don't. Some are duplicates. You're not sure which.

You attach the whole folder. You click send. You hold your breath.

Three days later your accountant replies: "Can you organize these by year and vendor? I can't tell which Stripe invoice goes with which year."

You sigh. You spend a Saturday renaming files.

This entire scenario is avoidable. There is exactly one folder structure your accountant wants, and it is boring.

Table of Contents

What CPAs actually ask for
Why vendor-grouping wins
The structure most freelancers actually have
The structure that wins
What AutoFileEmail produces
The cross-reference moment
When the structure breaks down
What your CPA does NOT want
How to get there from here
The bottom line

What CPAs actually ask for

I asked four. Three solo CPAs and one mid-sized firm partner. The answers were nearly identical.

When you hand over a Drive folder, they want:

Top level: tax year. 2025, 2024, 2023. Not "2025 taxes" or "TY2025" or "Tax Year 2025." Just the year. Sortable. Unambiguous.
Second level: by vendor. One folder per vendor. Vendor name as the folder. stripe.com, aws.amazon.com, notion.so. Or if the firm prefers, the human-readable vendor name. Either works as long as it's consistent.
Third level: by month. 01, 02, 03. Two-digit so they sort correctly. 1, 2, 3 won't sort right and will annoy your CPA on principle.
Files inside. Original PDFs, ideally with the date in the filename so they're sortable inside the folder.

That's the whole structure. Three levels deep. No "Income vs Expenses" split. No category tags. No spreadsheet alongside.

Why so flat? Because the CPA's actual job - cross-referencing categories to vendors - is something they do in their software, not in your folder. They don't need you to pre-categorize. They need you to surface the documents in a way they can scan.

Illustration of CPA asks: year, vendor, and month folders with PDFs

Why vendor-grouping wins

You might think "expenses by category" makes more sense. Software, travel, meals, etc. It does, in your head. But the CPA doesn't think in your categories. They think in their chart of accounts.

Your "software" might be their "Cost of Goods Sold" if your business uses the SaaS tools to deliver services. Or it might be "G\&A Software." It depends on the entity type, what you do, and how aggressive the CPA is. Pre-categorizing gets in their way.

Vendor groupings, on the other hand, are universal. Stripe is Stripe. AWS is AWS. The CPA opens the aws.amazon.com folder, sees 12 monthly invoices, sums them, drops the total into whatever line on the return matches their categorization scheme.

There's also an audit angle. If the IRS asks "show me the AWS expenses for 2024," you need to be able to produce them, not by remembering which category you tagged them under, but by walking to the vendor folder. The IRS audits by vendor, not by your category labels.

Vendor grouping wins visual

The structure most freelancers actually have

Let's be honest about the starting point.

Most solo founders have one of these three setups, and none of them are what their accountant wants:

Setup 1: The graveyard folder.

Drive/
  Receipts/
    invoice.pdf
    invoice (1).pdf
    Stripe-Feb.pdf
    Stripe-March.pdf (?)
    AWS_Invoice_4824.pdf
    800 more files]

Setup 2: The aspirational year folder.

Drive/
  2024 Receipts/
    [200 files, mostly named "invoice.pdf"]

Setup 3: The one that started organized and got abandoned.

Drive/
  2024/
    Stripe/
      Jan.pdf
      Feb.pdf
    AWS/
      [empty - you forgot in March]
  2025/
    Stripe/
      [empty - you forgot in January]

Setup 3 is the most common. Started with good intentions. Maintained for 2 months. Quietly abandoned by April.

Common freelancer folder structures

The structure that wins

Here is what your accountant actually wants:

Drive/
  Receipts/
    2024/
      stripe.com/
        01/
          2024-01-15-stripe-invoice.pdf
          2024-01-31-stripe-payout.pdf
        02/
          2024-02-15-stripe-invoice.pdf
        ...
      aws.amazon.com/
        01/
          2024-01-03-aws-invoice.pdf
        02/
          2024-02-03-aws-invoice.pdf
        ...
      notion.so/
        ...
    2025/
      stripe.com/
        ...

Three levels. Year, vendor, month. Files dated inside. Done.

Your CPA opens 2024/stripe.com/, sees twelve subfolders, knows there should be twelve months of receipts. If 04 is missing, they ask. Quick check.

Open 2024/aws.amazon.com/04/, see one PDF, know that's April's AWS bill. If there are two PDFs, one is probably a usage report and one is the invoice. The CPA can tell at a glance.

This is not a clever structure. It's a structure that survives contact with reality.

Structure that wins folder tree

What AutoFileEmail produces

We built our filing engine around exactly this structure because, when we asked CPAs the same question, this is what they kept describing.

The folder pattern is /AutoFileEmail/{vendor-domain}/{YYYY}/{MM}/. So the actual layout in your Drive looks like:

Drive/
  AutoFileEmail/
    stripe.com/
      2025/
        01/
          2025-01-15-invoice.pdf
        02/
          2025-02-15-invoice.pdf
      2026/
        01/
          2026-01-15-invoice.pdf
    aws.amazon.com/
      2025/
        ...
    notion.so/
      ...

Notice: vendor is the second level (instead of year first). For a solo founder filing one set of taxes a year, this is functionally identical for the CPA - they sort by year inside each vendor folder. But it has one nice property: the vendor list is visible at a glance from the top, which makes it easier to spot "wait, why is there a random-saas.com folder, did I sign up for that?"

If your CPA strongly prefers year-first, the same files can be reorganized in 5 minutes with a Drive script or by drag-drop. The hard part - getting the receipts into folders at all - is the part you don't have to do. The structural shuffle is trivial once the data is in.

AutoFileEmail folder structure

The cross-reference moment

Here is what your CPA is actually doing when they open your folder.

They have a chart of accounts. It looks like:

Software & subscriptions
Cloud hosting
Professional services
Travel
Meals
Office supplies
Marketing & advertising
Bank fees
Etc.

They're going to sum your receipts into those buckets.

When the folder is per-vendor, the cross-reference is fast:

stripe.com/ -> Bank fees (or fee revenue offset, depending)
aws.amazon.com/ -> Cloud hosting
notion.so/, linear.app/, figma.com/, cursor.so/ -> Software & subscriptions
delta.com/, marriott.com/ -> Travel
doordash.com/, ubereats.com/ -> Meals (with caveats)
legalzoom.com/, gusto.com/ -> Professional services

Five minutes, the CPA has a category total. Versus 45 minutes opening 200 files in a flat folder to figure out which vendor each one came from.

That 40-minute delta is what you're paying for when you pay your CPA hourly. Or what you're forcing them to eat if you have a flat-rate engagement, which they remember next year when they quote you.

When the structure breaks down

A few honest edge cases.

Vendors with subdomains. noreply@billing.stripe.com and notifications@stripe.com are the same vendor. AutoFileEmail collapses both to stripe.com so the folder count stays sane. If you build this manually, do the same thing.

Receipts with no PDF. Some vendors send receipts as inline HTML in the email body. We don't catch those today (no attachment to file). For those, your options are: forward to a dedicated label and screenshot to PDF later, or pester the vendor to email actual PDFs.

Joint personal and business. If you use one Gmail for both, expect a personal-vendor.com folder mixed in with the business ones. Worth setting up a rule (or a separate inbox) before you backfill years of data and discover your Netflix receipts in your tax folder.

Vendors that change names. AWS sends from amazon.com. Apple sends from apple.com. Google sends from a few subdomains, all collapsing to google.com. If a vendor rebrands (Twitter to X, Receipt Bank to Dext) the folder name will reflect whichever domain they used. Your CPA can handle this; they've seen worse.

What your CPA does NOT want

Things to skip:

A spreadsheet alongside the folder, especially one you made the night before. Your categorizations will be wrong (per the chart of accounts they actually use). They will ignore the spreadsheet.
Every receipt in one giant folder, even if it's named neatly.
Sub-folders by category ("Software", "Travel"). Useful for you, in your way. Not useful for the CPA.
Annotated PDFs with your handwritten notes. Pristine originals are what survives an audit.
A Hubdoc dashboard login. They have their own software. They don't want yours.

If you've been [paying for Hubdoc or Dext and your CPA still asks for a folder anyway, that's the signal that the OCR was for somebody else.

How to get there from here

If you're starting from a graveyard folder, two paths:

Path 1: Manually. Pick a free Saturday. Sort by sender. Drag files into vendor folders. Sort by date. Drag into month folders. It will take 4-8 hours per tax year. Doable for a single year if you're organized.

Path 2: Automatically. Connect Gmail and Drive to AutoFileEmail. Forward filing handles the future. The Backfill Pack ($29 for one tax year, $59 for three years, $99 lifetime) walks the inbox and produces this exact structure for years past. The 3-Year Pack typically catches what an audit letter asks for. (Detailed walkthrough: backfill 3 years in an afternoon.)

Either way, the destination is the same. The folder structure is the deliverable.

The bottom line

Your accountant doesn't want OCR. They don't want a dashboard. They don't want your spreadsheet.

They want a Drive folder, organized by year, then by vendor, then by month, with the original PDFs inside. That's it.

You can build that folder by hand once a year, hating it. Or you can wire up auto-filing and have the folder maintain itself.

If you're a freelancer, the tax-time workflow is built around exactly this. Connect Gmail, get the folder structure, hand it to your CPA. Free for one inbox. The folder is yours forever, even if you cancel.

Try it. Worst case you save your accountant 40 minutes and yourself a passive-aggressive email.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/drive-folder-structure-accountant-wants/the-one-drive-folder-structure-your-accountant-wants-banner-9801e7de-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[GDPR for One-Person Businesses: Receipts Edition]]></title>
            <link>https://autofile.email/blog/gdpr-one-person-businesses-receipts</link>
            <guid isPermaLink="false">https://autofile.email/blog/gdpr-one-person-businesses-receipts</guid>
            <pubDate>Fri, 05 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[GDPR applies to your receipt folder if customers' data lives in it. Here's the practical guide for solo founders, no legalese, with the lawful bases that matter.]]></description>
            <content:encoded><![CDATA[GDPR for One-Person Businesses: Receipts Edition

You're a one-person business. You sell something to people in Europe. You get an email from a customer that says "under GDPR, please send me all the personal data you hold about me."

You panic. You've never thought about your receipt folder as "personal data." Is it? Probably some of it.

You google "GDPR small business receipts." You get 4,000 words of legalese that does not answer your question.

This article tries to. I am not a lawyer. This is a practical primer, not legal advice. If you sell B2C in the EU at any volume, talk to a real lawyer. For everyone else, here's the working understanding.

Table of Contents

Who counts as a controller
When receipt-handling becomes "processing personal data"
The six lawful bases
Tax law trumps the right to erasure
What you must actually do
What the apps you use have to do
Where AutoFileEmail sits
What the practical reality looks like
The bottom line
References

Who counts as a controller

GDPR uses two main words: controller and processor.

A controller decides what personal data gets collected and why. A processor handles the data on behalf of a controller.

When you receive a receipt - say, a Stripe payout invoice - the personal data on that receipt is mostly yours (your business address, your bank routing). You're the data subject of your own business records. GDPR doesn't really apply to you protecting yourself from yourself.

Where it gets interesting: when receipts contain personal data about other people. Customers, mostly.

If you sell B2C and your Stripe receipts include buyer email addresses, buyer names, sometimes home addresses - now you, the one-person business, are a controller of those buyers' personal data.

This means GDPR applies. Not "kind of." Actually applies. Even at one-person scale.

One-person business owner evaluating GDPR roles with a chalkboard labeled Controller and Processor

When receipt-handling becomes "processing personal data"

Article 4(2) of GDPR defines "processing" as basically any operation on personal data. Collecting, storing, organizing, retrieving, consulting, erasing.

So:

Saving customer-bearing receipts to a folder = processing
Letting a CPA look at them = processing (and "transfer to a third party")
Letting a SaaS tool OCR them = processing (and "transfer to a third-party processor")

If you sell B2B and your receipts only contain your own details, you're mostly out of the heavy GDPR territory. Your business data isn't covered.

If you sell B2C, even modest amounts, you're in.

The threshold question: does any receipt you receive contain identifiable personal data about a person who isn't you? If yes, GDPR applies to how you handle that file.

Receipt handling illustration showing folder, receipts and a laptop to visualize processing personal data

The six lawful bases

GDPR Article 6 lists six lawful bases for processing personal data. Most don't apply to a solo founder filing receipts. The two that do:

1. Legal obligation (Art. 6(1)(c)). You're legally required to keep tax records. In most EU member states, that's 6-10 years (Germany: 10 years for invoices; Ireland: 6 years; France: 10 years for accounting). You retain receipts because the law says you must.

2. Legitimate interest (Art. 6(1)(f)). Running your business, including knowing what your expenses were, is a legitimate interest. As long as it doesn't override the rights of the data subjects.

For receipt handling specifically, "legal obligation" is your strongest base. You're not retaining customer emails because you want to - you're retaining them because tax authorities can audit you for ~7 years and demand receipts that may incidentally include those emails.

The other four bases (consent, contract, vital interests, public task) rarely apply to receipt-filing scenarios.

Balance scales showing Legal obligation and Legitimate interest as lawful bases for processing

Tax law trumps the right to erasure

This is the part that confuses a lot of one-person businesses.

GDPR gives data subjects a "right to erasure" (Art. 17), often called the right to be forgotten. A customer can email you and demand you delete their personal data.

But Article 17(3) carves out exceptions. Including:

"...for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject..."

Translated: if EU/national law requires you to keep the record, you can refuse the erasure request for that specific purpose.

Tax records are exactly this. If a French customer asks you to delete your invoice to them and you're legally required to keep that invoice for 10 years, you respond:

"We've removed your data from our marketing systems and customer communications. We're retaining the invoice with your name on it for tax purposes (Article 17(3)(b) GDPR; legal obligation). We'll delete it when the retention period expires."

You don't get to refuse erasure for everything. Only for the parts the law requires you to keep. The Stripe receipt with their email on it that you legally must keep for tax: yes, retain. Their email in your newsletter list: delete.

Tax law trumps erasure concept with 'Tax Records' document and erased data symbol

What you must actually do

The practical solo-founder GDPR checklist for receipt handling:

1. Know what data you have. Article 30 asks for a "record of processing activities." For solo founders below 250 employees (you), this is technically optional unless processing is regular and risky. But the ICO and most EU regulators have said in guidance: just keep a one-page list anyway. It takes 20 minutes. Saves you in an audit.

A solo-founder version:

"I receive receipts containing my own data and occasional customer data."
"I store them in Google Drive."
"I share them with my accountant once a year."
"Retention: 7 years."
"Lawful basis: legal obligation (tax records)."

2. Have a privacy policy. If you have any kind of website or take any payments from EU residents, you need a privacy policy that mentions you retain transaction records for tax purposes. Most generated templates cover this; just check yours does.

3. Have a DPA (Data Processing Agreement) with anyone who processes personal data on your behalf. This includes your email host, your cloud storage, your accountant, and any "receipt app" you use.

Google has a DPA. Microsoft has a DPA. Stripe has a DPA. Most legitimate SaaS tools have one - check their /legal/dpa or /security page. If they don't, that's a red flag.

4. Respond to data subject requests within 30 days. If a customer emails you asking for their data, you have a clock. Acknowledge fast, respond within 30 days. Doesn't mean you have to give them what they ask for, just respond.

5. Report breaches within 72 hours. If your Drive gets hacked or your laptop with the receipt folder gets stolen, you have 72 hours to report to your supervisory authority.

That's the working list.

gdpr-what-you-must-do

What the apps you use have to do

Every receipt-handling tool you use needs to be evaluated through this lens.

If the app OCRs your receipts and stores extracted data, that data is "processing." The app is your processor. You need a DPA with them. They need to be GDPR-compliant for transfers (especially US apps relying on the EU-US Data Privacy Framework).

This is non-trivial. Some tools' OCR happens on US servers. Some on EU servers. Some don't tell you. Some "anonymize" the data before training their models, which is its own gray area under GDPR's definition of personal data.

There's a practical ranking of receipt apps by privacy posture elsewhere on this blog. The short version: more OCR usually means more data flowing through more systems, which means more GDPR exposure.

Where AutoFileEmail sits

Plain-language version of our position:

We don't read receipt contents. We only handle email metadata (sender domain, date, subject, message ID, filename) needed to file. The PDF content stays untouched.
We don't store the receipts. They go from your email provider straight to your Google Drive. We don't keep copies on our servers.
You're the controller of the receipts. They live in your Drive, under your Google account, in your jurisdiction. We're a thin processor of email metadata only.
DPA available at autofile.email/legal. Standard terms.
Hosting: Cloudflare Workers (mostly EU edge for EU users) plus a Postgres database for our own metadata, in a US region. Email metadata flows through the EU-US Data Privacy Framework.
Cancel and delete: there's almost nothing to delete because we never had receipt content. We retain OAuth tokens and email metadata, both deleted on account closure.

This is, honestly, an easier compliance posture than tools that OCR receipts. Not because we're clever - because we deliberately don't see the content. You can't leak data you don't have.

If you want the long version of the design philosophy, it's in why we don't OCR your receipts.

What the practical reality looks like

If you're a one-person business in or selling to the EU:

Receive receipts. Some include customer data.
They file into /AutoFileEmail/{vendor}/{YYYY}/{MM}/ in your own Drive.
Once a year, share the year's folder with your accountant. (Your accountant has their own DPA with you. Or should.)
Retain for 6-10 years per your country's tax law.
Customer asks for erasure: respond, identify what you legally must keep vs what you can delete, document your reasoning, send the response.
Customer asks for a copy of their data: download what you have, redact unrelated parties, send it within 30 days.

The key insight: receipt PDFs in your own Drive are easier to handle for GDPR than receipt data spread across an OCR vendor's database, your accountant's software, your invoice tool, and a marketing tool. Fewer systems, fewer DPAs, fewer ways for data to leak.

The bottom line

GDPR for a one-person business handling receipts is mostly about three things:

Knowing where customer personal data lives (in receipts, sometimes).
Having a lawful basis for keeping it (usually: legal obligation for tax records).
Having DPAs with the third parties who touch it.

If your CPA's spreadsheet has a column for customer email, that's the part GDPR cares about. The receipt PDF is yours, in your Drive, full stop. The fewer apps that touch the content of the PDF, the smaller your GDPR exposure.

AutoFileEmail is built around the "fewer apps touch the content" idea. Free for one inbox. Files land in your own Drive, under your control, GDPR-friendly by architecture rather than by promise. If you'd rather see how it stacks against the OCR-heavy tools, there's a Hubdoc comparison too.

This is not legal advice. If you have actual EU customers at any volume, talk to a lawyer. For most solo founders with occasional EU customers, the basics covered here are enough to stay out of trouble.

References

GDPR Article 6 (lawful bases): gdpr-info.eu/art-6-gdpr/
GDPR Article 17 (right to erasure): gdpr-info.eu/art-17-gdpr/
GDPR Article 30 (records of processing): gdpr-info.eu/art-30-gdpr/
ICO guidance for small organisations: ico.org.uk/for-organisations/sme-web-hub/
EU-US Data Privacy Framework: dataprivacyFramework.gov
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/gdpr-one-person-businesses-receipts/gdpr-one-person-businesses-receipts-banner-1980d949-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Backfilling 3 Years of Receipts in an Afternoon]]></title>
            <link>https://autofile.email/blog/backfill-3-years-receipts-afternoon</link>
            <guid isPermaLink="false">https://autofile.email/blog/backfill-3-years-receipts-afternoon</guid>
            <pubDate>Tue, 09 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Got an IRS letter or just years of unfiled receipts in Gmail? Here's how the 3-Year Backfill Pack turns 22 hours of clicking into one afternoon.]]></description>
            <content:encoded><![CDATA[Backfilling 3 Years of Receipts in an Afternoon banner

It's Tuesday. You open your email. There it is. A letter from the IRS. The subject line ends in "...regarding your 2023 tax return."

You stop breathing for a second.

You read it. They're not auditing you. They're "requesting documentation" for the Schedule C deductions you took. Receipts. For 2023, 2024, and 2025. Within 30 days.

Three years of receipts. From an inbox where you've been "filing" them by leaving them in Gmail since 2022.

You pour coffee. You open Gmail. You search has:attachment from:stripe. 142 results. You search has:attachment from:aws. 218 results. You search has:attachment from:notion. 47. You start counting in your head and stop somewhere past 800.

The good news: this is fixable in an afternoon.

Table of Contents

The math nobody runs
The afternoon version
What the result looks like
Vendors you forgot about
What backfill cannot do
What it costs vs. doing it yourself
How the backfill job actually runs

The math nobody runs

Let's count what's actually in there.

A typical solo founder gets receipts from 15-30 vendors. Some monthly (Stripe, AWS, Notion, Linear, Figma, Cursor). Some annual (domain registrars, Adobe yearly plans, accountant software). Some weird and bursty (Vercel after a usage spike, Cloudflare when you bought a domain you forgot about).

A reasonable average: 50 receipts a month landing in your inbox. Some months 30, some 80. Doesn't matter for the math.

Three years × 12 months × 50 = 1,800 PDFs.

If you do this manually, the workflow is:

Open email. (3 seconds)
Right-click attachment, "Save link as." (4 seconds)
Pick the right Drive folder, or create one if it doesn't exist. (15-30 seconds)
Rename the file because half of them are called invoice.pdf. (10 seconds)
Drag to Drive. (5 seconds)

Average per receipt: 30-60 seconds, if you're moving fast and not getting distracted.

1,800 receipts × 45 seconds = 22.5 hours.

That's three full workdays. Of right-clicking. Without a single break, while not getting any other work done.

Founder calculating three years of receipts totals with 1,800 PDFs represented visually

The afternoon version

The 3-Year Backfill Pack is $59. It walks the inbox once. Lands every PDF in /AutoFileEmail/{vendor}/{YYYY}/{MM}/.

Rough timeline:

Sign up: 30 seconds
Connect Gmail: 30 seconds
Connect Drive: 30 seconds
Buy the 3-Year Pack: 60 seconds
Pick the date range (e.g. "Jan 1 2023 to today"): 10 seconds
Confirm: 1 click
Wait

The "wait" part depends on inbox size. For 1,800 attachments across three years, expect 30-90 minutes of unattended runtime. Gmail's API rate limits are the bottleneck, not our code. We file roughly 30-60 attachments per minute on a healthy connection.

You start it after lunch. You go reply to the IRS letter, reassure your CPA, and make another coffee. By 4pm the folder is built.

Step-by-step setup for the 3-Year Backfill Pack workflow

What the result looks like

Open Drive. Navigate to /AutoFileEmail/. You see something like:

AutoFileEmail/
  stripe.com/
    2023/
      01/  (3 PDFs - payout, invoice, dispute notice)
      02/  (2 PDFs)
      03/  (3 PDFs)
      ...
    2024/
      ...
    2025/
      ...
  aws.amazon.com/
    2023/
      01/  (1 PDF - monthly bill)
      ...
  notion.so/
    2023/
      ...
  github.com/
    2023/
      ...
  25 more vendor folders]

Every receipt where it should be. Vendor folder, year, month. Original PDF, prefixed with the email date so it sorts correctly.

The AWS folder will have ~36 PDFs, neatly nested into 36 month folders. The Stripe folder will have more, because Stripe sends multiple email types per month (payouts, invoices, dispute notifications).

This is the structure your accountant wants. We did a [whole article on the folder structure if you're curious why this specific layout.

AutoFileEmail folder structure in Drive with stripe.com, 2023/01, aws, notion folders

Vendors you forgot about

This is the moment most people don't expect.

When you open the backfilled folder, you will find vendors you forgot you used. Some examples from real users (anonymized):

An Adobe trial from 2023 that auto-renewed to a $239 annual plan you didn't notice.
A Webflow charge from 2024 for a project you abandoned.
Three separate domain registrar accounts (Namecheap, Porkbun, Cloudflare Registrar) because you couldn't decide which one you preferred.
A Notion AI add-on. A second Notion workspace. A third Notion workspace owned by the founder of a side-project that died.
The "free" GitHub Copilot trial that became a $19/mo charge after the trial. For 18 months.
ConvertKit (now Kit). Substack Pro. Beehiiv. Did you really need three newsletter platforms in 2024?

These are deductible expenses that your past self either forgot or never told the accountant about. Backfilling surfaces them.

The flip side: you may also surface charges you should cancel. The audit was annoying, but the audit-prep just saved you ~$200/mo in dead subscriptions.

Vendors you forgot about discovered in the backfill process displayed on a corkboard

What backfill cannot do

Honest about the limits.

Receipts that aren't attachments. If a vendor sends an HTML email receipt with no PDF attached, we can't file it. There's no document to file. You'd need to print-to-PDF those manually if your accountant insists on having them as files. Most CPAs accept the email itself as evidence.

Vendors that consolidate. Apple sends a single monthly receipt for all your subscriptions. So your apple.com folder will have ~36 PDFs (one per month, three years), not one per app. Your CPA can handle this, but you'll need to do the breakdown if you want per-app categorization.

Receipts older than your retention. Gmail has no inherent retention limit, but if you delete receipt emails, they're gone. We can only file what's still in the inbox.

Outlook, iCloud, IMAP backfill. Today, backfill works for Gmail. Outlook+M365 is on the roadmap. iCloud Mail too. Sign up and we'll email when those are live.

More than 50,000 emails. The Lifetime Backfill Pack ($99) caps at 50,000 emails for one walk. Solo founders almost never hit this. If you have a marketing inbox with newsletters mixed in, the cap can sneak up on you. The cap is to keep us from accidentally OOM-killing on someone's 200K-email inbox.

Limitations of backfill: receipts without attachments, not OCR, Gmail-only currently

What it costs vs. doing it yourself

The honest comparison.

DIY: 22.5 hours × your hourly rate. If you bill yourself at $75/hr, that's $1,687.50 of opportunity cost. Plus the 3-day delay before you can respond to the IRS. Plus the 12% chance you give up halfway through and just send the IRS what you have.

3-Year Pack: $59. One afternoon, mostly unattended. Same result.

Hubdoc + 3-year backfill: Hubdoc charges per receipt for backfill at OCR rates. Plus the $30+/mo subscription. We've seen Hubdoc backfill quotes for solo founders at $300-600 for similar volumes. Then ongoing monthly fees forever.

Receipt Bank/Dext + 3-year backfill: Similar shape. They're built for accounting firms, who pass costs to clients. Solo founders pay retail.

The $59 number isn't pricing magic. It's that we don't OCR. (More on why we don't OCR your receipts.) We're moving files, not reading them. Moving files is cheap. The price reflects the actual work.

How the backfill job actually runs

For the technically curious, the engine in plain English:

Authenticate with Gmail (read-only scope, encrypted refresh token).
List message IDs in the date range. Gmail's API returns these in batches of 500. For three years, expect 5,000-30,000 message IDs depending on your inbox.
For each message, check if it has attachments. If yes, fetch the message metadata and the attachment.
Pull the sender's registrable domain (noreply@billing.stripe.com -> stripe.com).
Compute the target Drive path: /AutoFileEmail/stripe.com/2024/03/.
Create the folder if it doesn't exist (cached, so we don't re-create on every file).
Upload the attachment with a date-prefixed filename.
Record (account_id, message_id, filename) in our metadata table for dedup.
Move on.

The dedup index is the part that matters when forward-filing is also running. If a backfill job and a forward-filing job both encounter the same email, only one writes the file. No duplicates.

Step-by-step setup for the 3-Year Backfill Pack workflow

The IRS angle

If you're reading this article because of an IRS letter, a few things to know:

The IRS does not care about your folder structure. They care that the receipt is genuine, matches a transaction in your bank or card statement, and corresponds to the deduction you took.

What they want to see: original PDFs from the vendor, with the vendor's name and date visible. The PDFs we file are bit-for-bit identical to what the vendor sent. They're as audit-ready as the originals.

What they want NOT to see: edited PDFs, "summary" spreadsheets in place of receipts, OCR'd text without the original. The original PDF is the receipt. Anything derived from it is supplementary.

You don't need to print these. You don't need to physically organize anything. A Drive folder shared with your accountant (who shares it with the IRS via their portal, if requested) is the modern audit-response format.

The bottom line

Three years of receipts is a one-afternoon problem if you have the right tool and a $59 budget. It's a three-day problem if you do it manually.

The receipts already exist in your Gmail. You don't have to find them - they're already there. You just need them to land in the right folders. That's a filing job, not an extraction job, not an OCR job.

If you're staring at an audit letter, or just at January's "this is the year I'll be organized" feeling, pick a Backfill Pack and run it. It's $29 for one tax year, $59 for three years, $99 for everything to ever exist.

For the ongoing job after the backfill finishes: forward filing is free for one inbox, keeps the structure current as new receipts arrive. The freelancer workflow is built around this loop.

Worst case: it's an afternoon. Best case: it's the difference between a calm IRS response and a panic.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/backfill-3-years-receipts-afternoon/backfilling-receipts-afternoon-banner-1dc17881-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Filing Emails Into Drive: Zapier vs IFTTT vs Purpose-Built]]></title>
            <link>https://autofile.email/blog/filing-emails-drive-zapier-ifttt-vs-purpose-built</link>
            <guid isPermaLink="false">https://autofile.email/blog/filing-emails-drive-zapier-ifttt-vs-purpose-built</guid>
            <pubDate>Fri, 12 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Should you use Zapier, IFTTT, Power Automate, Apps Script, or a purpose-built filer for receipts? Honest comparison with real pricing and limits.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for comparing Zapier, IFTTT, Power Automate, Apps Script, and a purpose-built filer

"Just use Zapier."

This is the answer you'll get on every Reddit thread, every Twitter reply, every Stack Overflow question about saving Gmail attachments to Drive.

It's a fine answer. For some jobs.

For receipt filing specifically, it's a tier of overhead and cost most people don't realize they're signing up for. By the time you've built the third multi-step Zap to handle a new vendor, you've spent more time configuring Zapier than you would have spent right-clicking the receipts manually.

Let's actually compare. Zapier vs IFTTT vs Microsoft Power Automate vs Apps Script vs a purpose-built filer. Honest pros and cons. Real pricing. Real limitations.

Table of Contents

The job we're comparing
Option 1: Zapier
Option 2: IFTTT
Option 3: Microsoft Power Automate
Option 4: Google Apps Script
Option 5: A purpose-built filer (us, but also the category)
The honest comparison table
Where Zapier still wins
Where Power Automate is genuinely competitive
The "I'll just write a script" trap
The bottom line

The job we're comparing

The job: every PDF attachment that arrives in Gmail (or Outlook) should automatically end up in a Google Drive folder, organized by sender domain and month. So noreply@billing.stripe.com becomes /Receipts/stripe.com/2026/04/ with the original filename.

This is a deceptively specific job. Most automation tools can do "Gmail attachment to Drive folder." Few can do "Gmail attachment to a folder hierarchy that's derived from the sender's domain, with the year and month auto-inferred from the email date, and the folder auto-created if it doesn't exist."

Let's see how each option handles it.

Option 1: Zapier

The default answer. Let's actually run the numbers.

The basic Zap: "New Attachment in Gmail" trigger -> "Upload File in Google Drive" action. This works. For one folder.

The problem: Zapier's Drive action requires you to pick a folder. A specific folder. By name. So one Zap files everything to the same folder.

To file by sender domain, you need:

A trigger that filters by sender (or you handle all senders in one Zap).
A Code or Formatter step that extracts the registrable domain from the email address.
Another step that builds the folder path.
A Find/Create Folder step (multiple, one per folder level).
The upload step.

That's a 5-7 step Zap. Per attachment processed.

Zapier pricing (May 2026):

Free: 100 tasks/month, 5 Zaps. A "task" is each step that fires.
Starter: $19.99/mo, 750 tasks. ~1 user.
Professional: $49/mo, 2,000 tasks. Multi-step Zaps unlocked at full feature parity.
Team: $69/mo+, more tasks.

Math: A 6-step Zap processes 100 attachments and burns 600 tasks. At Professional pricing, you've used 30% of your monthly tasks for 100 receipts. A solo founder with 50 receipts/month is at the Starter tier minimum, more realistically Professional once you have multiple Zaps for different jobs (CRM, Slack, etc.).

Annual cost: $239-588.

What it actually does well: Once configured, runs reliably. Zapier's reliability is excellent. They've solved the "what if a step fails halfway through" problem.

What it doesn't: Auto-discovery of new vendors. If a vendor you've never received from sends a receipt, your Zap either dumps it in a default folder, fails silently, or you've coded the domain-extraction logic well enough to handle it. Most users don't.

Studio Ghibli-inspired scene of a person evaluating automation options to file Gmail attachments into Drive by domain and date

Option 2: IFTTT

Same shape, different package.

IFTTT's "Gmail attachment to Drive" applet works for the simple case. The complex case (sender-domain folder hierarchy) is harder than Zapier because IFTTT's filter logic is weaker.

Pricing (2026):

Free: 2 applets. Yes, two. The free tier was deprecated.
Pro: $3.99/mo, 20 applets, faster polling.
Pro+: $14.99/mo, unlimited applets, custom queries.

Annual: $48-180.

What it does well: Dirt cheap. Good for simple "if X then Y" automation.

What it doesn't: Limited filter logic. No "extract domain from email address" without external scripting. No "build folder path" without help. You'll end up with everything in one folder again.

For receipt filing specifically, IFTTT's ceiling is too low. Skip.

Zapier workflow planning for Gmail-to-Drive with multi-step logic in a warm Studio Ghibli style

Option 3: Microsoft Power Automate

If you're an M365 user, this is the "free with your existing subscription" option.

Power Automate has a Gmail connector and a Drive connector. (Also OneDrive, naturally.) You can build a "when new email arrives" flow with attachment handling, condition logic, and folder routing.

Pricing:

Free with M365 Business plans (capped at certain action types, called "premium connectors").
Per-user plan: $15/mo for premium connectors.
The free tier actually does cover most receipt-filing scenarios if you're routing to OneDrive.

Annual: $0-180.

What it does well: Real conditional logic. You can write a flow that extracts the domain, builds a path, creates folders, and uploads. It's possible.

What it doesn't: Building that flow takes 2-4 hours. The flow editor is powerful but the UX is corporate-Microsoft, not consumer-friendly. You will spend an evening on this.

Once built, runs well. But you're maintaining a flow that breaks if Microsoft renames an action (which they do).

For people already in the M365 ecosystem and willing to spend a Saturday, Power Automate is legit. For everyone else, it's overkill.

Power Automate flow diagram for Gmail attachments to Drive with domain-based folders

Option 4: Google Apps Script

Free. Powerful. Yours forever.

Apps Script lets you write JavaScript that runs against Gmail, Drive, and most Google APIs. You can write a script that:

Searches Gmail for messages with attachments (filter by date, sender, label, whatever).
Iterates each message.
Pulls attachment metadata.
Computes the target folder path.
Creates folders as needed.
Saves the attachment.
Logs what it did.

In about 80 lines of JS. Genuinely.

Pricing: $0.

What it does well: Free, deeply customizable. If you're a developer, this is the "right" answer for ad-hoc filing.

What it doesn't:

6-minute execution timeout per run. If you trigger on a backlog, you have to chunk.
Quota limits on Drive API (1 billion calls/day across all Google users, per-user limits much lower). For a working inbox, fine. For a backfill of 10,000 emails, you'll hit per-user quotas mid-run and have to retry.
Trigger reliability. The "every 5 minutes" trigger can silently stop firing. You won't notice until tax time.
OAuth refresh tokens expire if the script doesn't run for 6 months. You'll come back to "your script needs reauthorization" emails.
No UI. You're maintaining code in Google's editor.

For a developer with 4 hours and willingness to maintain it: legitimate option. For everyone else: a slow-motion abandonment in 8 months.

Illustration of a purpose-built filer AutoFileEmail filing receipts automatically

Option 5: A purpose-built filer (us, but also the category)

A purpose-built filer is built around exactly this job. It knows what an "email attachment" is, it knows what a "registrable domain" is, it knows that you want a hierarchical folder structure, and it doesn't make you wire up the steps.

You connect Gmail. You connect Drive. It runs.

AutoFileEmail specifically:

Free: 1 inbox, forward filing forever, 30-day historical preview on signup.
Backfill Packs (one-time): $29 for one tax year, $59 for three years, $99 lifetime.
No monthly fee for the basic case.
Pro tier ($14.99/mo) coming with multi-inbox, post-MVP.

Annual cost for a typical solo founder: $0-99 once.

What it does well: The exact job, no configuration. Auto-discovers new vendors. Auto-creates folders. Survives Gmail API hiccups. Logs what it filed.

What it doesn't: This narrow job. We do not move files between Slack and Trello. We don't watch your CRM. We don't hook into your podcast feed. If you wanted that, you wanted Zapier.

Illustration of a purpose-built filer AutoFileEmail filing receipts automatically

The honest comparison table

| Tool | Setup time | Annual cost | Auto-discovers vendors | Works without coding |
|------|-----------|-------------|------------------------|----------------------|
| Zapier | 1-2 hours | $240-590 | Maybe (depends on Zap) | Yes |
| IFTTT | 30 min | $48-180 | No | Yes |
| Power Automate | 2-4 hours | $0-180 | If built well | Sort of |
| Apps Script | 4+ hours | $0 | Yes | No |
| AutoFileEmail | 90 seconds | $0-99 once | Yes | Yes |

Where Zapier still wins

Worth being clear: Zapier is a great product for what it does. It just isn't the right product for "file every receipt that lands in my inbox."

Zapier wins for:

Cross-system workflows. "When a Stripe payment succeeds, post to Slack and create a Trello card and update Notion."
Logic across many tools. Zapier connects to 6,000 apps. AutoFileEmail connects to email and cloud storage.
Custom triggers. RSS feeds, webhooks from arbitrary services, custom HTTP endpoints. Zapier eats this for breakfast.
CRM integrations. AutoFileEmail will not put a row in your HubSpot. Zapier will.

If you're building a multi-app automation, Zapier is the right hammer.

For the specific receipt-filing job, a purpose-built filer is faster, cheaper, and stays out of your way. The same way a CSV-to-database tool is better than writing a Zapier zap to do the import.

Where Power Automate is genuinely competitive

If you're already on M365, Power Automate is the closest competitor for the receipt-filing use case. Free with your subscription, capable enough.

The trade is time. You spend 2-4 hours building a flow that does what AutoFileEmail does out of the box. If your hourly value is high, that's expensive labor. If you enjoy building flows, it's a Saturday well spent.

For Outlook users specifically, Power Automate also has the advantage of being a Microsoft product talking to a Microsoft email service. Fewer auth surprises.

(AutoFileEmail Outlook+M365 support is on the roadmap. Today, the working integration is Gmail+Drive. The other connectors are coming, but if you need Outlook today, Power Automate is your stop-gap.)

The full integrations roadmap lives at /integrations.

The "I'll just write a script" trap

The first version takes a weekend. It works. You're proud. Six months later you have 200 lines of code, a lurking double-file bug, and a trigger that quietly stopped firing when you rotated your Google password.

This is the gravity of side projects. They start as 80-line scripts and become maintenance burdens. The maintenance never makes it to your calendar. (More on this trade-off in auto-filing PDFs.)

The bottom line

Each tool has a job:

Zapier: cross-system workflows where you need 6,000 connectors.
IFTTT: cheap, simple, two-action automations.
Power Automate: M365 users who want a flow they own and maintain.
Apps Script: developers who like maintaining code.
AutoFileEmail: the specific receipt-filing job, no setup, no monthly fee.

For the narrow job of "receipts from email into Drive folders," a purpose-built filer is the cheapest, fastest, lowest-overhead option. Connect Gmail in 30 seconds. Free for one inbox. The structure is the structure your accountant wants. The cost is zero unless you backfill years of history.

For everything else, go pick the right tool for that job. Zapier and Power Automate are excellent. They just aren't built for this.

If you're already on a tax-time deadline, the 3-Year Backfill Pack walks the inbox once and produces the same folder structure forward-filing maintains.

Try the filer. If it doesn't fit, the Zap will still be there. None of these tools mind if you switch.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/filing-emails-drive-zapier-ifttt-vs-purpose-built/filing-emails-drive-automation-ghibli-banner-e95c20ab-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Stripe + AWS + Notion Receipts: The Founder's Tax-Time Checklist]]></title>
            <link>https://autofile.email/blog/stripe-aws-notion-receipts-founders-tax-checklist</link>
            <guid isPermaLink="false">https://autofile.email/blog/stripe-aws-notion-receipts-founders-tax-checklist</guid>
            <pubDate>Tue, 16 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The 15 vendors a typical solo founder pays every month, where the receipts arrive, and how to make sure all 15 land in one Drive folder.]]></description>
            <content:encoded><![CDATA[Stripe, AWS, and Notion receipts: a founder's tax-time checklist in a cozy Studio Ghibli style

It's the second Saturday in March. You sit down to do the founder version of taxes. You're solo, you're an LLC or sole prop, you take Stripe revenue, and you pay for 15 things every month that all live in your Gmail.

You start a list. Stripe. AWS. GitHub. Vercel. You get to seven and your brain stalls. Was it Loom or Riverside? Was the Notion bill on the personal card or the business card? Did Anthropic charge you twice in February?

This is the moment most founders give up and just guess.

This post is the antidote. The 15 vendors most solo SaaS founders actually pay, the exact email addresses those receipts come from, and how to make sure every single one ends up in a real folder before the next tax season.

Table of Contents

The 15 vendors a typical solo founder pays
Where each receipt actually arrives in Gmail
Why Gmail buries them
What sender-domain extraction does
The printable checklist
The quirky senders that trip people up
The 30-day preview that catches mistakes
Why this matters for actual taxes
TL;DR

The 15 vendors a typical solo founder pays

I pulled this from looking at my own credit card statement and three founder friends' statements. Yours will overlap by 80%.

Revenue side (1099-K territory):

Stripe - your payouts and fees

Infra and dev tools:
2\. AWS - hosting, S3, RDS
3\. Cloudflare - DNS, Workers, CDN
4\. Vercel - frontend hosting
5\. GitHub - private repos, Actions minutes

Product and design:
6\. Notion - docs, the second brain
7\. Linear - issue tracking
8\. Figma - design files

Comms:
9\. Slack - if you have a community or contractors
10\. Zoom - calls
11\. Loom - async video

AI and APIs:
12\. OpenAI (ChatGPT Plus or API)
13\. Anthropic (Claude API)
14\. ElevenLabs - voice generation, if you make videos

Email and transactional:
15\. Resend or Postmark - sending email from your app

That's the spec. Fifteen vendors. Roughly $400 to $1,200 in monthly recurring spend if you're a real-deal solo SaaS. Every one of them sends you a receipt by email. Every one of them buries it somewhere.

Where each receipt actually arrives in Gmail

This is the thing nobody tells you. Every vendor sends from a slightly different address, and Gmail doesn't group them.

| Vendor | Sender address | Subject pattern |
|---|---|---|
| Stripe | billing@stripe.com, noreply@stripe.com | "Your invoice from Stripe" |
| AWS | aws-receipts@amazon.com, no-reply-aws@amazon.com | "Amazon Web Services Invoice" |
| GitHub | support@github.com, noreply@github.com | "Your GitHub receipt" |
| Vercel | invoice+...@vercel.com | "Your Vercel Invoice" |
| Cloudflare | billing@cloudflare.com | "Your Cloudflare Invoice" |
| Notion | team@makenotion.com | "Receipt from Notion Labs" |
| Linear | support@linear.app | "Linear Invoice" |
| Figma | receipts@figma.com | "Your Figma receipt" |
| Slack | feedback@slack.com | "Slack invoice" |
| Zoom | no-reply-zoom@zoom.us | "Zoom invoice" |
| Loom | team@loom.com | "Your Loom receipt" |
| OpenAI | receipts+ac_...@stripe.com | "Your receipt from OpenAI" |
| Anthropic | noreply@anthropic.com | "Your Anthropic receipt" |
| ElevenLabs | team@elevenlabs.io | "ElevenLabs invoice" |
| Resend | billing@resend.com | "Resend Invoice" |

Two things to notice. First, OpenAI bills through Stripe, so the receipt looks like it's from Stripe but it's an OpenAI charge. Second, Anthropic uses a generic noreply@anthropic.com because they handle billing in-house. Third, AWS uses both aws-receipts@amazon.com and no-reply-aws@amazon.com interchangeably, and they often switch without warning.

If you've ever tried to set up Gmail filters for these vendors, you've felt the pain. The address strings change. The subject lines change. The display name flips between "Stripe" and "Stripe Billing" and "Stripe, Inc."

Why Gmail buries them

Gmail's threading model assumes you want to read emails. Receipts aren't reads. They're file-and-forget.

When AWS sends you 14 receipts in 14 months, Gmail threads 13 of them under one subject if the subject is identical, hides 12 of them in the collapsed view, and shows you the most recent one only. Your filter that says "label as Receipts" works, but the inbox view still says "Inbox (1) - AWS Receipt" because of the thread collapse.

Then you search from:aws-receipts has:attachment in March and Gmail returns 9 results when there should be 12. Three are missing because the sender address changed for two months when AWS migrated their billing system. You don't notice until your CPA asks where the August invoice went.

This isn't theoretical. It's why founders consistently undercount their AWS spend by one or two months at tax time.

What sender-domain extraction does

AutoFileEmail flattens all of this. Every email gets reduced to its registrable domain. The folder name is the domain. End of story.

Some examples of how the extraction handles real-world cases:

noreply@aws.amazon.com -> folder amazon.com
aws-receipts@amazon.com -> folder amazon.com
billing.us@stripe.com -> folder stripe.com
receipts+ac_xyz@stripe.com -> folder stripe.com (the OpenAI-via-Stripe charges land here too, which is correct, since the legal vendor on the receipt PDF is OpenAI but the email sender is Stripe; the PDF inside the folder shows OpenAI)
noreply@anthropic.com -> folder anthropic.com
invoice+12345@vercel.com -> folder vercel.com
team@makenotion.com -> folder makenotion.com (Notion's actual corporate domain; the folder name is verbatim)

Subdomains, prefixes, plus-addressing - none of it matters. The registrable domain wins. Twelve months of AWS bills land in /AutoFileEmail/amazon.com/2026/. Twelve months of Stripe land in /AutoFileEmail/stripe.com/2026/. The thread-collapse problem is gone because every receipt is now a file, not an email.

The printable checklist

When March arrives, walk through this list. For each vendor you actually use, click into the corresponding Drive folder and count files. If the count matches your card statement, you're done.

 ] /AutoFileEmail/stripe.com/2026/         - count = 12 (monthly fees)
[ ] /AutoFileEmail/amazon.com/2026/         - count = 12 (AWS)
[ ] /AutoFileEmail/cloudflare.com/2026/     - count = 12
[ ] /AutoFileEmail/vercel.com/2026/         - count = 12
[ ] /AutoFileEmail/github.com/2026/         - count = 12
[ ] /AutoFileEmail/makenotion.com/2026/     - count = 12
[ ] /AutoFileEmail/linear.app/2026/         - count = 12
[ ] /AutoFileEmail/figma.com/2026/          - count = 12
[ ] /AutoFileEmail/slack.com/2026/          - count = 12
[ ] /AutoFileEmail/zoom.us/2026/            - count = 12
[ ] /AutoFileEmail/loom.com/2026/           - count = 12
[ ] /AutoFileEmail/openai.com/2026/         - count = 12 (or in stripe.com if billed via Stripe)
[ ] /AutoFileEmail/anthropic.com/2026/      - count = variable (usage-based)
[ ] /AutoFileEmail/elevenlabs.io/2026/      - count = 12
[ ] /AutoFileEmail/resend.com/2026/         - count = 12

If any folder is missing files, two things to check. First, did you sign up for that vendor mid-year? An eight-month count is correct for a vendor you started using in May. Second, did the vendor change their billing email address? If your amazon.com folder has 9 files and you know AWS billed you 12 times, search Gmail for "AWS invoice" directly and see if any landed at a different sender address. Forward them to AutoFileEmail's address and they'll re-file correctly.

The quirky senders that trip people up

A few vendors deserve special mention because their setup confuses people.

Anthropic. Sends from noreply@anthropic.com for both API billing and Claude Pro subscriptions. The receipts are clean PDFs. Domain extraction nails it: anthropic.com, no prefix gymnastics needed.

OpenAI via Stripe. OpenAI's API billing routes through Stripe, so the email comes from a Stripe-owned address. The PDF attachment shows OpenAI as the vendor, but the email sender is Stripe. AutoFileEmail files by sender domain, so these end up in stripe.com. If you want them in their own folder, you can manually move the PDFs once a year. Most founders just leave them in stripe.com because the PDFs are clearly labeled OpenAI inside.

Vercel. Vercel uses plus-addressing (invoice+abc123@vercel.com) so each invoice has a unique sender for tracking. Gmail filters break on this; you'd need a wildcard. Domain extraction strips the plus part and lands everything in vercel.com. No filter setup needed.

AWS. AWS sends from at least three different addresses depending on which service is billing you (EC2, S3 standalone, Marketplace). All of them are *.amazon.com and all collapse to amazon.com. So your AWS folder has the bill from your main account, the bill from your Marketplace subscription, and the standalone S3 invoice from that side project, all together.

GitHub. Sometimes GitHub sends invoices, sometimes payment confirmations. Both go to github.com folder. Sponsorships and Actions minutes also land here.

Notion. Filed under makenotion.com, not notion.so. This is correct - their billing entity is Notion Labs, Inc., and their billing domain is makenotion.com. Verbatim domain wins.

The 30-day preview that catches mistakes

When you sign up, AutoFileEmail runs a 30-day historical preview for free. This is the moment to spot vendors you forgot about. Open the preview folder. If it's empty for cloudflare.com and you definitely pay Cloudflare, two possibilities: their billing email goes to a different inbox (work vs personal Gmail), or your Cloudflare receipts don't have PDF attachments (they sometimes link to a download instead).

Either way, you find out before paying for a [Backfill Pack. The preview is the smoke test.

If the preview catches all 15 vendors, the Tax Year Pack at $29 will catch 12 months of historicals in an afternoon. If it misses three vendors, fix those first - usually it's a forwarding rule or a different inbox - then run the backfill.

Why this matters for actual taxes

Schedule C deductions for a solo SaaS founder are dominated by these 15 vendors. Software, hosting, contractor tools. The IRS doesn't ask for them upfront - you just deduct the total - but if they ever do ask, you need the PDFs.

Founders who hand their CPA a vendor-organized folder save hours of CPA billable time. Founders who hand their CPA "here's my Gmail" end up with the CPA either guessing the totals or charging an extra $200 in admin time to dig through the inbox.

Either way, the math favors filing.

TL;DR

Fifteen vendors. Fifteen folders. One Drive root.

Connect Gmail and Google Drive once. The folder structure builds itself. Sender domains collapse correctly even for the weird ones (noreply@aws.amazon.com becomes amazon.com, plus-addressed Vercel invoices become vercel.com).

Print the checklist above, run it once in March, and you'll know in 90 seconds whether your tax-time filing is complete.

Free for one inbox. No subscription, no per-receipt fees. Two clicks to set up. Then forget about it until you actually need the folders.

15-vendors-solo-founders-receipts

Gmail inbox and domain-based folders organizing receipts in a warm Studio Ghibli style

Gmail thread buries receipts due to threading; a founder looks for receipts

Printed checklist with 15 vendors checked off for tax-time
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/stripe-aws-notion-receipts-founders-tax-checklist/stripe-aws-notion-receipts-founders-tax-time-banner-36b84062-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Your Accountant Doesn't Need OCR. Your Accountant Needs Folders.]]></title>
            <link>https://autofile.email/blog/accountant-doesnt-need-ocr-needs-folders</link>
            <guid isPermaLink="false">https://autofile.email/blog/accountant-doesnt-need-ocr-needs-folders</guid>
            <pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Receipt apps sell OCR and QuickBooks sync. Indie-founder CPAs say they just want the PDFs in named folders. Here's why hand-categorized data makes things worse.]]></description>
            <content:encoded><![CDATA[Your Accountant Doesn't Need OCR. Your Accountant Needs Folders.

Every receipt SaaS pitch ends the same way.

"Save your accountant time. Extract line items. Sync to QuickBooks. Categorize automatically with AI."

It sounds great. It's also wrong.

Talk to actual CPAs who serve solo founders and freelancers, and the universal feedback is: don't send me your AI-categorized exports. Send me the PDFs.

This post is about why that gap exists and what your CPA actually wants from you.

Table of Contents

What receipt-app marketing promises
What CPAs actually say
Why OCR creates false data
Why hand-categorization is worse than no categorization
What "the PDFs in named folders" actually means
How AutoFileEmail's folder structure mirrors audit format
The "but my accountant uses QuickBooks" objection
What this means for tool selection
The bottom line

What receipt-app marketing promises

Open any Hubdoc or Dext or Receipt Bank or AutoEntry homepage. The pitch is consistent.

"Auto-extract data from invoices and receipts."

"Publish to QuickBooks, Xero, or Sage with one click."

"AI categorization saves hours of manual entry."

"Your accountant gets clean data, ready to file."

The implicit promise: by paying $25 to $35 a month, you save your accountant time, which saves you money, which makes the subscription pay for itself.

The math sounds tidy. The math is also based on an accounting workflow that doesn't apply to most one-person businesses.

Marketing promises of receipt apps like OCR and auto-categorization

What CPAs actually say

Here's the paraphrased common feedback when you ask CPAs who specialize in solo founders, freelancers, and small LLCs what they want from clients:

"Just give me the PDFs. I have the bank and credit card statements. I cross-reference. I don't trust the OCR."

"The categorizations are wrong half the time. A 'meals' charge is actually 'office supplies' from the same vendor. The AI doesn't know."

"I spend more time fixing the auto-categorized data than I would entering it from PDFs myself."

"For my one-person clients, I bill by the return, not by the hour. Extra data doesn't save them money. It just gives me more work to undo."

"My QuickBooks has 80% of the data already through the bank feed. The receipts are the substantiation, not the data source."

These aren't outliers. They're the modal CPA opinion for the solo-founder segment. Listen to a few episodes of any indie-founder accounting podcast and you'll hear the same thing in different words.

CPAs' feedback about PDFs vs OCR and manual processes

Why OCR creates false data

OCR isn't 100% accurate. Even the best models hit 95% to 98% on clean PDFs and drop to 80% on noisy receipts.

Sounds high. Now do the math. If you have 250 receipts in a year and OCR is 95% accurate per field, and there are 4 fields per receipt (vendor, date, amount, line item), the chance that all 250 receipts are perfectly extracted is roughly 0.95 to the power of 1000. Effectively zero.

In practice this means: out of your 250 receipts, maybe 30 to 50 have at least one wrong field. Wrong amount. Wrong date. Wrong vendor name (because the receipt header says "ACME LLC" but the invoice says "Acme Tools, Inc."). Wrong category, because the AI guessed.

Your CPA doesn't see "this field is 95% confident." They see a CSV. They have to either trust it or audit it. If they audit it, you've paid $25 a month for a CSV that the CPA verifies against the original PDF anyway. If they trust it, you've paid $25 a month to systematically introduce errors into your tax return.

This is the dirty secret of the OCR-receipt category. The technology is impressive. The technology is also not the bottleneck.

OCR data extraction errors and misreads on receipts

Why hand-categorization is worse than no categorization

The other option receipt apps offer: you categorize. Drag-and-drop the receipts into "meals", "supplies", "software", "travel". The app exports a tidy spreadsheet.

This is worse than OCR.

You are not a tax accountant. You don't know that the Notion subscription is "software" if it's used for client work, but "dues and subscriptions" if it's general operations. You don't know that a meal with a contractor is "meals" at 50% deductible (post-TCJA) but a meal you ate alone on a business trip is something else entirely. You don't know that your AWS bill is "cost of goods sold" if you're a SaaS, but "operating expenses" if you're a consultant.

Your CPA knows this. They went to school for it. They keep up with the IRS code revisions. They will recategorize 40% of what you guessed because the rules are not intuitive.

So when you hand them a pre-categorized spreadsheet, you've created a document they have to undo. Which is why the interview feedback above lands on "just give me the PDFs."

Hand-categorization confusion and incorrect classifications

What "the PDFs in named folders" actually means

The CPA workflow looks like this:

Pull bank and credit card statements. These are the ground truth for what was spent.
For each transaction, find the matching receipt PDF.
Categorize each transaction per the current tax code.
Reconcile. Question anything that looks weird.
File.

Step 2 is the bottleneck. Step 2 is where you can help. Everything else is the CPA's job.

To make step 2 fast, the CPA needs receipts that are:

Findable. Sorted by vendor, then by date. Not categorized. Not in one big folder.
Complete. Every charge on the statement has a matching PDF.
Native. The original PDF the vendor sent, not a re-rendered OCR-flattened version.

Three requirements. Notice what's missing: AI, categories, line items, sync.

Folder structure by vendor and year matching audit formats

How AutoFileEmail's folder structure mirrors audit format

Here's a thing CPAs don't tell you upfront: the IRS and most state tax authorities, when they request documentation in an audit, ask for it by vendor and by year.

"Please provide all 2024 invoices from Amazon Web Services."

"Please provide receipts for travel meals over $75 for tax year 2025."

The standard audit document request format is vendor-sorted, year-sorted. Not category-sorted. Not OCR-extracted.

AutoFileEmail's folder structure:

/AutoFileEmail/
  amazon.com/
    2025/
      01/
      02/
      ...
  stripe.com/
    2025/
      ...

This is exactly the format the IRS expects. It's also exactly the format your CPA wants. By coincidence (or rather, by not over-engineering), the simplest possible filing system happens to be the format both audiences need.

When the audit request comes in, you click into amazon.com/2024/, zip it, send. Done in two minutes. The CPA does the same when they're prepping your return.

Compare this to the Hubdoc workflow. Receipts are stored in Hubdoc's app. Categorized into Hubdoc's category schema. Tagged with Hubdoc's tags. Synced to QuickBooks via Hubdoc's mapping. To respond to an audit request, you need to either export from Hubdoc or pull from QuickBooks. Either way, you're now dependent on the apps continuing to exist and continuing to support your data format. Hubdoc has shut down major features in the past; the lock-in is real.

A folder of PDFs in your own Drive is durable. Apps come and go.

How AutoFileEmail's folder structure mirrors audit format

The "but my accountant uses QuickBooks" objection

Some CPAs do use QuickBooks Online and want bank-feed reconciliation with attached receipts.

Two things on this. First, attaching a receipt PDF to a QuickBooks transaction works fine if the PDF exists in Drive - your CPA pulls it themselves. They don't need an OCR app to do it. Second, the bank feed already has the transaction data (date, vendor, amount). The receipt is the substantiation document, not the data source. OCR re-extracting data that's already in the bank feed is duplicate work.

If your CPA truly wants OCR for their workflow - say they're managing 50 clients and need automation - then the CPA should pay for the OCR tool, not you. That's a pattern Dext and Hubdoc support directly with their accountant-firm pricing tiers. The firm pays. The clients hand over PDFs. Everyone wins.

What this means for tool selection

If you're a solo founder or freelancer hiring a CPA once a year, your job is:

Get every receipt PDF into a folder structure organized by vendor and year.
Hand the folder over in March.

You don't need OCR. You don't need categorization. You don't need sync.

What you need is: when an email with a PDF attachment arrives, file it into the right folder automatically. That's it. That's the entire job.

Which is what AutoFileEmail does. No OCR. No AI. No category guessing. No sync. Just folders.

Free for one inbox. The premium tier is for backfilling years of historical email, not for adding more features. We don't sell you AI. We sell you organization.

The bottom line

Your CPA wants the raw PDFs. Not the OCR. Not the categorized export. The PDFs.

Receipt apps sold the dream of "save your accountant time" by extracting data. The actual time savings come from organization, not extraction. Folders by vendor and year solve 90% of the problem. The remaining 10% is your CPA's job, and they're better at it than any AI.

Connect Gmail and Drive in two minutes. Hand your CPA a folder in March. Done.

Your accountant doesn't need OCR. Your accountant needs folders.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/accountant-doesnt-need-ocr-needs-folders/your-accountant-doesnt-need-ocr-your-accountant-needs-folders-banner-db3e4cc0-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[What the IRS Actually Needs From Your Receipts (Boring But Free)]]></title>
            <link>https://autofile.email/blog/what-irs-needs-from-receipts</link>
            <guid isPermaLink="false">https://autofile.email/blog/what-irs-needs-from-receipts</guid>
            <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The 5 things every business expense receipt must show, the retention windows, and what 'adequate records' means in IRS speak. Pubs cited.]]></description>
            <content:encoded><![CDATA[What the IRS Actually Needs From Your Receipts (Boring But Free) banner image

Most receipt advice you'll find online is from accounting firms trying to sell you software.

This post is from the IRS itself. Specifically, IRS Publication 583 (Starting a Business and Keeping Records), Publication 463 (Travel, Gift, and Car Expenses), Publication 17 (Your Federal Income Tax), and a couple of revenue procedures that govern digital storage.

Boring sources. Free to read. They tell you exactly what a receipt has to show, how long you have to keep it, and what "adequate records" means in plain English.

If you've been overthinking your filing system, the actual rules are simpler than receipt-app marketing makes them sound.

Table of Contents

The 5 things every receipt must show
The $75 rule
The 3-year, 6-year, 7-year retention rules
What "adequate records" actually means
Travel, meals, and entertainment - special rules
Digital storage rules - Rev. Proc. 97-22 and 98-25
What this means for your filing system
TL;DR

The 5 things every receipt must show

Per Publication 583, a receipt for a business expense has to substantiate five elements:

The amount. What did you pay.
The date. When did you pay it.
The vendor. Who did you pay.
What was purchased. A description of the product or service.
The business purpose. Why this expense relates to your business.

The first four are usually printed on the receipt itself. The fifth is the one that trips people up. The IRS doesn't require the business purpose to be on the receipt, but it does require you to be able to explain it. A meal at a restaurant is fine; a meal at a restaurant where you discussed a contract with a client and can name the client is what you actually need.

For most software and infrastructure expenses (your AWS bill, your Vercel bill, your Notion subscription), the business purpose is obvious from the vendor name. You don't need a separate note. For meals, travel, and gifts, you do.

Five elements every receipt must show: amount, date, vendor, description, business purpose

The $75 rule

There's a specific threshold most founders don't know about. Per Publication 463, expenses under $75 generally don't require a receipt. You can substantiate them with other records (a bank statement, a card statement, a contemporaneous note in a logbook).

The exceptions are lodging (always need a receipt regardless of amount) and certain transportation costs.

In practice this means: that under $10 ChatGPT subscription doesn't legally require you to keep the receipt, and neither does an under $50 Uber to a client meeting. But you still need to substantiate that it was a business expense, and the easiest way is to keep the receipt anyway.

The $75 threshold has been in place since the early 2000s and hasn't been adjusted for inflation. Worth being aware of, but practically: just keep all the receipts. The marginal cost is zero if you've automated filing.

Receipts under $75 do not require a receipt but can be substantiated

The 3-year, 6-year, 7-year retention rules

This is where most founders get confused. The IRS has multiple retention windows depending on the type of record.

3 years - the standard. The IRS has 3 years from the date you filed your return to assess additional tax. Keep records for 3 years after filing for any year where you reported income normally.

6 years - if you understated income by more than 25%, the assessment window doubles to 6 years. So if there's any chance of a reporting error, 6 years is the safe minimum.

7 years - if you claimed a loss from worthless securities or bad debt deduction, 7 years.

Indefinitely - if you didn't file a return, or filed a fraudulent return. Don't do this.

Until you sell - records related to property (depreciation, basis adjustments) need to be kept until the period of limitations expires for the year you dispose of the property. So if you bought a $4,000 laptop in 2024 and depreciated it over 5 years, the receipt has to live until at least 2030, possibly later.

The pragmatic answer for solo founders: keep everything for 7 years minimum. Storage is free. Drive doesn't charge you per file. There's no reason to delete anything.

The IRS source for this is Publication 583, page 13: "Period of Limitations." Worth a 5-minute read once.

IRS retention rules 3, 6, and 7 years explained with calendar and file boxes

What "adequate records" actually means

The IRS uses the phrase "adequate records" in multiple publications. It's not legally defined to a single standard, but the working definition combines guidance from Pub 583, Pub 463, and Treasury Regulation 1.6001-1.

Adequate records means:

Permanent. Not on a Post-it that fades. Digital files count if they're stored durably.
Accessible. You can produce them on demand within a reasonable time (typically 30 days for an audit response).
Organized. The IRS uses the word "orderly" - meaning the auditor shouldn't have to dig through your inbox to find what they asked for.
Substantiating. They prove the five elements above.

A folder of PDFs in Google Drive, organized by vendor and year, hits all four. A 12,000-email Gmail inbox with no labels does not - "accessible" implies you can find specific records on request, and "organized" requires more than full-text search.

This matters because if the IRS audits you and you can't produce records that meet the standard, they can disallow the deduction. You eat the tax plus penalties. The whole point of filing receipts is that you never end up in this situation.

What "adequate records" means: organized digital files

Travel, meals, and entertainment - special rules

Post-TCJA (the Tax Cuts and Jobs Act, effective 2018), entertainment is no longer deductible. Meals are mostly 50% deductible if business-related. Travel is generally 100% deductible.

But all three categories have heightened substantiation requirements per Publication 463. For each meal expense over $75, you need:

The amount of the expense
The time and place
The business purpose
The business relationship of the people present

That last one is the kicker. For a meal with a client, you need to record (somewhere, doesn't have to be on the receipt itself) who you ate with and what business you discussed. A Google Calendar entry from that day works. A sticky note in your wallet works. An email confirmation works.

This is the one area where the receipt alone isn't enough. Receipt + context. The receipt goes in your filing system; the context can live in your calendar or notes.

For travel, the substantiation is similar. Hotel folio (always required regardless of amount), flight confirmation, the dates and business reason for the trip. If you're a freelancer who takes occasional client trips, this is straightforward. If you're a digital nomad who tries to deduct half your nomadic life, the substantiation gets harder.

Travel, meals, and entertainment IRS rules with substantiation examples

Digital storage rules - Rev. Proc. 97-22 and 98-25

This is the question every founder asks: "Can I throw away the paper receipts if I have digital copies?"

Answer: yes, since 1997.

Revenue Procedure 97-22 establishes that taxpayers can store records electronically as long as the system meets certain requirements. The IRS updated this in Rev. Proc. 98-25 specifically for "automatic data processing" records.

The requirements, simplified:

The digital record must be a true copy of the original, with all relevant data intact.
The system must be capable of indexing, retrieving, and reproducing the records on demand.
You must keep the records for the same retention period as you would the originals.

PDFs from email vendors (Stripe, AWS, etc.) qualify automatically - they're already digital originals. PDFs you scanned from paper receipts qualify if you scanned them properly (legible, complete, not just a photo of a folded receipt).

What doesn't qualify: a screenshot of an email confirmation that doesn't include the full transaction details. A hand-typed summary of a receipt. An OCR'd CSV without the original PDF backup.

The IRS specifically allows electronic storage. You don't need to keep paper copies. You don't need a special "audit-compliant" storage system. A Drive folder is fine, provided you can find specific records on demand.

IRS retention rules 3, 6, and 7 years explained with calendar and file boxes

What this means for your filing system

The IRS doesn't care what app you use. It cares that you can produce the requested records, organized, in a reasonable time.

The minimum viable system:

Receipts stored as PDFs (the original from the vendor email).
Organized by vendor and year, so you can find "all 2024 AWS invoices" in 30 seconds.
Backed up so you don't lose them in a hard-drive crash.
Retained for 7 years minimum.

That's it. No OCR. No categorization. No special compliance software. The IRS rules don't mandate any of those things.

This is also exactly what AutoFileEmail produces. New email with attachment arrives, attachment lands in /AutoFileEmail/{vendor-domain}/{year}/{month}/. PDFs are the original from the vendor. Folder structure is vendor + year. Drive's own retention is effectively unlimited as long as you keep the account.

The system that meets every IRS requirement happens to be the simplest possible system. Which is good news, because the alternative - paying $30 a month for OCR you don't need - doesn't make you any more compliant. It just makes you poorer.

The 75 rule

TL;DR

The IRS rules for receipts are boring and free. Five elements per receipt, 7-year retention, digital is fine since 1997, organized by vendor and year is "adequate."

AutoFileEmail produces a Drive folder that meets every one of these requirements out of the box. No OCR, no AI, no per-receipt fees.

Free for one inbox. Connect Gmail and Drive in two minutes. The IRS won't care which app you used. They'll care that you can produce the folder.

The receipts most founders fail to produce in an audit aren't missing because the filing system was wrong. They're missing because there was no filing system. Have one. The IRS doesn't ask for more than that.

Sources cited: Publication 583 (Starting a Business and Keeping Records), Publication 463 (Travel, Gift, and Car Expenses), Publication 17 (Your Federal Income Tax), Revenue Procedure 97-22, Revenue Procedure 98-25, Treasury Regulation 1.6001-1. All free at irs.gov/forms-pubs.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/what-irs-needs-from-receipts/what-the-irs-receipts-banner-de5d3d09-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Gmail Filters For Receipts: 5 You Should Set Today]]></title>
            <link>https://autofile.email/blog/gmail-filters-for-receipts-5-to-set-today</link>
            <guid isPermaLink="false">https://autofile.email/blog/gmail-filters-for-receipts-5-to-set-today</guid>
            <pubDate>Fri, 26 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Five Gmail filters that label and organize incoming receipts. Plus the catch nobody mentions: filters label, but they don't actually file.]]></description>
            <content:encoded><![CDATA[Gmail filters for receipts: 5 essential rules to set today for freelancers

Gmail filters are powerful and underused.

If you've never set one up, the gist: you write a rule like "from this address, with these words, do this thing." Gmail applies it on every incoming email forever.

For receipts specifically, the right set of filters can turn a chaotic inbox into a tagged, organized stream of incoming PDFs. Five filters cover most of what a freelancer or solo founder needs.

This post walks through those five filters with the exact Gmail syntax. Then, halfway through, the catch nobody mentions: filters label, but they don't actually file anything. Which means you're still doing manual work when March rolls around.

Table of Contents

Filter 1: SaaS vendors with attachments
Filter 2: subject-line catch-all
Filter 3: annual subscription renewals
Filter 4: dynamic from-list builder
Filter 5: never-spam transactional emails
What actual filing looks like
When Gmail filters still make sense
TL;DR

Filter 1: SaaS vendors with attachments

The bread-and-butter filter. Captures the 15 to 20 SaaS vendors most founders pay every month and labels them.

Gmail filter syntax:

from:(stripe.com OR aws.amazon.com OR github.com OR vercel.com OR cloudflare.com OR makenotion.com OR linear.app OR figma.com OR slack.com OR zoom.us OR loom.com OR anthropic.com OR openai.com OR resend.com OR digitalocean.com)
has:attachment

Action: apply label Receipts/SaaS, mark as read (optional), skip inbox (optional if you want them auto-archived).

How to set it up: Gmail -> Settings (gear icon) -> See all settings -> Filters and Blocked Addresses -> Create a new filter. Paste the from: query, check the "Has attachment" box, hit "Create filter," then check "Apply label" and pick or create Receipts/SaaS.

The good: every email from any of these vendors with an attachment now lives under one label. Searching label:Receipts/SaaS shows all your SaaS receipts in one stream.

The bad: you have to keep the from: list current. New vendors don't appear. Vendors who change their billing email address (AWS does this every 18 months or so) silently stop matching the filter. You'll find out next March when there's a gap in your records.

Filter 2: subject-line catch-all

A broader net for invoices and receipts that don't come from your known vendor list.

subject:(invoice OR receipt OR payment OR billing OR "your order")
has:attachment
-from:(linkedin.com OR pinterest.com OR meetup.com)

Action: apply label Receipts/Pending. Skip inbox optional.

The exclusions matter. LinkedIn sends "your invoice for the LinkedIn ad" emails that are not your normal SaaS bills. Pinterest sometimes uses "receipt" in marketing subject lines. Meetup occasionally sends invoice-themed promotional emails. Excluding these keeps your Receipts/Pending label clean.

The good: catches new vendors automatically. A new tool you signed up for that sends "invoice for \tool name]" lands here, even if you forgot to update Filter 1.

The bad: false positives. Marketing emails with "receipt" in the subject. Confirmations that aren't bills. You'll still spend 2 minutes a week reviewing the label.

Inbox view with subject-line catch-all Gmail filter for invoices/receipts

Filter 3: annual subscription renewals

Annual subs are the silent expense killer. They charge once a year, you forget about them, the receipt buries itself, and you can't find it in March.

subject:("annual" OR "yearly" OR "renewed" OR "renewal" OR "subscription renewed")
has:attachment

Action: apply label Receipts/Annual. Mark as important.

The good: annual receipts get extra visibility. Marking important means they show up in your priority inbox. You're less likely to miss one.

The bad: you still need Filter 1 or Filter 2 to catch the email in the first place if the vendor doesn't put "annual" in the subject. Belt and suspenders: this filter chains with the others.

Annual subscription renewal receipts organized with a Gmail filter

Filter 4: dynamic from-list builder

This is the trick most Gmail-power-users discovered the hard way.

When you find a new vendor invoice in your inbox, instead of editing Filter 1 by hand, do this:

Open the invoice email.
Click the three-dot menu next to the date.
Choose "Filter messages like these."
Gmail pre-fills from:billing@newvendor.com.
Modify the from to use the registrable domain, not the specific email: change billing@newvendor.com to *@newvendor.com (Gmail accepts wildcard-domain matching in some contexts; for older accounts use just newvendor.com).
Add has:attachment.
Create the filter, apply label Receipts/SaaS.

You're now up to N filters, one per vendor, each labeled the same way. This is more reliable than the OR-stuffed Filter 1 because each vendor has its own dedicated rule, and Gmail won't silently miss one if the OR query gets too long.

Gmail has a hard cap of about 1500 filters per account. You're not going to hit it.

The good: durable, granular, easy to debug if one vendor stops appearing.

The bad: takes effort to maintain. You're doing the receipt-app's job, manually, in Gmail.

Dynamic from-list builder workflow for Gmail filters

Filter 5: never-spam transactional emails

The single most-frustrating filter problem: Gmail occasionally marks legitimate vendor receipts as spam. New vendor, low sender reputation, generic subject line, suspicious-looking link in the email body. Gone.

Fix:

from:(stripe.com OR aws.amazon.com OR github.com OR vercel.com OR ...)

Action: never send to spam, never mark as important (so it doesn't crowd your priority inbox), apply label Receipts/SaaS.

This filter overrides Gmail's spam classifier for known senders. It does not protect against phishing pretending to be those senders, but it does prevent the legitimate receipts from being filtered out.

The good: no more "where's my AWS bill" panic.

The bad: same maintenance burden as Filter 1. Keep the list current.

Never-spam transactional emails filter preventing legitimate receipts from being marked as spam

This is the catch: filters don't actually file

Here's where the post pivots.

You've now set up 5 to 20 Gmail filters. Every receipt is correctly labeled. Your Receipts/SaaS label has 130 emails in it.

Now: it's March. Your CPA emails you. "Send me your 2025 receipts."

What do you do?

You open label:Receipts/SaaS. You see 130 emails. You click the first one. You click the attachment. You click "Save to Drive" or download. You repeat for the second email. And the third.

130 emails. 90 seconds each, including renaming the file so it's not called invoice.pdf and adding it to the right folder. That's 195 minutes. Three and a half hours.

Filters labeled the emails. They didn't file the attachments. The attachments still live inside the email body, and you have to extract them one by one.

This is the gap nobody tells you about when they say "just use Gmail filters."

What actual filing looks like

The thing you actually want is: when an email with an attachment arrives, save the attachment to the right folder in Drive automatically. No manual extraction. No "save to Drive" clicks.

That's what AutoFileEmail does. The setup is one connection (Gmail OAuth read-only) plus one connection (Drive drive.file scope). After that, every new email with a PDF attachment gets the PDF dropped into /AutoFileEmail/{sender-domain}/{year}/{month}/.

You don't need any of the five filters above. The sender-domain logic is built in, so AWS bills go to amazon.com, Stripe bills go to stripe.com, regardless of which billing address the vendor uses.

You also don't need the annual-renewal filter because every receipt lands in the year-and-month folder it was sent in. Annual subs hit December (or wherever the renewal lands), and they're trivial to find next year.

The only filter you really need:

has:attachment AND from:(*)
-> let AutoFileEmail handle it

Which is to say, no filter. Just connect [Gmail to Drive automatically and stop manually labeling things.

When Gmail filters still make sense

To be fair, Gmail filters aren't useless. They make sense if:

You don't want a third-party app reading your Gmail and you're committed to manual filing.
You only have 5 to 10 vendors and the maintenance is trivial.
You're using filters for non-receipt purposes (newsletters, project tags, etc.) and adding receipts is incremental.

If any of those describe you, set up filters 1, 2, and 5 above. Skip the others - they're high-maintenance, low-value.

If you're filing receipts, the Gmail filter approach hits a wall. Filters label, but they don't extract attachments. Filing means extracting.

TL;DR

Five Gmail filters get your receipts labeled and organized inside Gmail. They don't move attachments to Drive. They don't create folders. They don't reduce the manual work of extracting PDFs in March.

If your goal is "every receipt PDF lives in a Drive folder, organized by vendor and year, with zero ongoing effort," you need an actual filing tool - not a labeling system.

AutoFileEmail does the filing. Free for one inbox. Two-click setup. The five-filter Gmail system becomes a zero-filter system, because the filing happens automatically and you don't need labels to find anything.

Set the filters if you like. Then connect Gmail and Drive once, and watch the labels become irrelevant.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/gmail-filters-for-receipts-5-to-set-today/gmail-filters-receipts-5-you-should-set-today-banner-d6491c03-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[1099 vs W-2 Income: Filing Receipts When You Have Both]]></title>
            <link>https://autofile.email/blog/1099-vs-w2-filing-receipts-both</link>
            <guid isPermaLink="false">https://autofile.email/blog/1099-vs-w2-filing-receipts-both</guid>
            <pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Day job plus side hustle? The W-2 side rarely needs receipts. The 1099 side absolutely does. Here's how to keep them separate without losing your mind.]]></description>
            <content:encoded><![CDATA[Banner for 1099 vs W-2 income and filing receipts

Your day job. You also do freelance work on the side. Maybe Upwork. Maybe direct clients paying through Stripe. Maybe a mix.

In the eyes of the IRS, those are two completely different income types. W-2 from your employer. 1099 from your clients (or 1099-K from Stripe, or 1099-NEC from Upwork).

The receipts side of this gets confusing fast. Your W-2 mostly doesn't need receipts - your employer either reimburses you or doesn't, and either way the receipts go to them, not you. Your 1099 side absolutely needs receipts because every business expense reduces your self-employment tax.

The mistake most side-hustlers make: filing all receipts together, then trying to sort them out in March.

This post is the cleaner system.

Table of Contents

Why W-2 income mostly doesn't need receipts
Why 1099 income desperately needs receipts
The "is my AWS bill 1099 or W-2" question
What about Stripe payouts and 1099-K forms?
Why per-vendor folders make this easy
The vendor-domain folder approach
TL;DR

Why W-2 income mostly doesn't need receipts

When you're a W-2 employee, your taxes are simple. Your employer withholds. They send you a W-2 in January. You report the wages and pay any difference.

Business expenses for W-2 employees are basically not deductible anymore. The Tax Cuts and Jobs Act eliminated the unreimbursed-employee-expenses deduction in 2018. So if your employer doesn't reimburse you for that conference ticket, you can't deduct it on your return either. (There are a few narrow exceptions for armed forces, qualified performing artists, and fee-basis government officials, but if you're reading this, those probably don't apply.)

Practical implication: if your employer reimburses an expense, the receipt goes to them through expense reports. If they don't reimburse it, you can't deduct it. Either way, you don't need to keep that receipt for your personal tax return.

The exception: if you're misclassified as an employee but really an independent contractor (rare but real), or if you have a side business that uses some of the same vendors. We'll get to the second case in a minute.

W-2 income mostly doesn't require receipts for deductions in tax filing

Why 1099 income desperately needs receipts

The 1099 side flips everything.

When you earn freelance income, you pay both regular income tax and self-employment tax (15.3% combined Social Security and Medicare). Every legitimate business expense reduces your net self-employment income, which reduces both taxes.

A $1,000 deductible expense saves you roughly $300 in combined federal taxes if you're in the 22% bracket plus self-employment tax. Real money.

The IRS knows this and audits Schedule C returns at a higher rate than W-2-only returns. They want to see receipts. Adequate records per Pub 583. Vendor name, date, amount, what was purchased, business purpose.

Lose a receipt, lose the deduction. Lose enough deductions, owe a lot more tax.

1099 income requires receipts for freelance expenses and tax deductions

The "is my AWS bill 1099 or W-2" question

A specific rule that catches people: an AWS bill is 1099 if your freelance project runs on AWS. It's not deductible against W-2 income, even if you're a software engineer at your day job and "use AWS at work." Your day job has its own AWS account; you're not paying that bill.

If your AWS bill includes both freelance project hosting and a personal hobby project, allocate. If your AWS bill is purely the freelance project, it's 100% deductible against 1099 income.

The corollary: if you accidentally signed up for AWS under your work email and your day job is paying it, that's not your expense at all. You're not deducting anything; the company is.

This sounds obvious, but at audit time the IRS does check the credit card statement against the deduction list. If a vendor charge was paid by your employer's card, it's not yours.

What about Stripe payouts and 1099-K forms?

Quick aside, because side-hustlers always ask.

If you take payment through Stripe (or PayPal, Etsy, eBay, etc.), and you cross certain thresholds, you'll get a 1099-K from the platform reporting your gross income. The threshold has been changing - $20,000 historically, dropped to $5,000 in recent years, eventually $600.

The 1099-K is income, not expense. It's not a receipt. It belongs in your "income" folder, not your AutoFileEmail receipt folders. Stripe sends it via a separate email in January.

Your AutoFileEmail folder for stripe.com will have your Stripe processing fee invoices throughout the year. Those are deductible expenses against your 1099 income. The 1099-K is reportable income on the other side of the ledger.

Same logic for Upwork's 1099-NEC, PayPal's 1099-K, Etsy, etc. Income forms go to "Income." Expense receipts go to AutoFileEmail folders.

Ten vendors organized into 1099, Mixed, and Pure W-2 buckets

Why per-vendor folders make this easy

The reason this approach works for side-hustlers specifically: the unit of analysis is the vendor, not the individual receipt.

In a "pile of receipts" approach, you have to decide for each receipt. 250 receipts a year. 250 decisions.

In a "folder per vendor" approach, you decide once per vendor. 15 to 30 decisions. The folder contains all the receipts from that vendor across the year, and they all get the same treatment.

This is why the AutoFileEmail folder structure mirrors what your CPA wants and why it happens to work for the side-hustle scenario. The folder is the deduction unit. The folder gets categorized once.

Compare this to a Hubdoc-style workflow where each receipt is OCR'd and tagged individually. You're now categorizing 250 line items, and the AI doesn't know which side of your income each one belongs to. You'd have to manually re-tag every one.

The vendor-domain folder approach

Here's the system that actually works for side-hustlers.

Step 1: Connect Gmail to Drive via AutoFileEmail. Every receipt with a PDF attachment lands in /AutoFileEmail/{sender-domain}/{year}/{month}/.

Step 2: At the end of the year, look at the vendor folders. For each vendor, ask: what side of my income does this expense relate to?

Three buckets:

Pure 1099 (deductible against freelance income):

Stripe (your freelance payouts and fees)
Domain registrar for your freelance site
Cloud hosting for projects you run independently
Software you use exclusively for client work

Mixed (partially deductible):

Notion (if used for both day job and side projects, allocate by time or storage)
A laptop you use for both (allocate by time-of-use percentage)
Internet at home (some IRS-allowed home-office portion)

Pure W-2 (not deductible to you):

Anything your employer reimbursed you for
Anything related to your day job that you paid out of pocket and your employer declined to reimburse (post-TCJA, these aren't deductible)
Personal subscriptions you use for entertainment

Once a year, in January or February, you walk through the AutoFileEmail folders and tag each vendor folder with its bucket. Most vendors are clear-cut.

Concrete example: 10 vendors, sorted

TL;DR

W-2 mostly doesn't need receipts. 1099 absolutely does. Mixing them is the most common side-hustler mistake.

Get receipts auto-filed by sender domain. Once a year, walk through the vendor folders and label each one as 1099, mixed, or W-2. Sum the 1099 and mixed (allocated) amounts. That's your Schedule C.

Connect Gmail and Drive in two minutes. Free for one inbox. The vendor-folder structure is the same whether you have one income source or three. Adding a side hustle doesn't add to your filing burden - just to your January labeling exercise.

Day job pays the bills. Side hustle pays the dreams. Don't let receipt chaos eat into either one.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/1099-vs-w2-filing-receipts-both/1099-vs-w2-income-receipts-banner-9ff5fc03-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[AI That Reads Your Invoices Is a Feature in Search of a Problem]]></title>
            <link>https://autofile.email/blog/ai-reads-invoices-feature-in-search-of-problem</link>
            <guid isPermaLink="false">https://autofile.email/blog/ai-reads-invoices-feature-in-search-of-problem</guid>
            <pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Every receipt SaaS launched an AI invoice extractor in 2024-2025. The pitch saves time you don't spend, costs money you don't need to spend, and indexes data you didn't want indexed.]]></description>
            <content:encoded><![CDATA[Contrarian view on AI receipt extraction for solo founders

In 2024, every receipt SaaS quietly added "AI" to their homepage.

Hubdoc. Dext. Receipt Bank. AutoEntry. Expensify. The smaller players too. Suddenly every product had an "AI invoice extractor" or "smart line item recognition" or "machine learning categorization."

The pitch was identical across all of them: AI reads your receipts so you don't have to.

There's a problem with this pitch. Most solo founders don't read their receipts in the first place. So saving us time on something we weren't doing is a feature in search of a problem.

This post is the contrarian take on AI receipt extraction. Why the trend exists. Why the math doesn't work for solo founders. And why AutoFileEmail is built around explicitly not having any of it.

Table of Contents

Why every receipt SaaS launched AI in 2024-2025
The pitch: save time on data entry
The reality: most solo founders don't do data entry
The math: GPU dollars vs solo-founder savings
The privacy hit nobody mentions
The counter-argument: AI does help large practices
What "no AI" means in practice
When "the file is enough" breaks down
The bottom line

Why every receipt SaaS launched AI in 2024-2025

The macro trend: GPT-4 dropped, OCR got 10x cheaper and 10x more accurate, and every B2B SaaS company panicked about their roadmap.

The micro trend at receipt SaaS specifically: their core product was OCR. Old-school OCR. The kind that worked on 80% of clean PDFs and broke on photos of crumpled receipts. With LLM-based extraction, the accuracy jumped to 95%+ and could handle messier inputs.

If you're Hubdoc, you have to ship this. Otherwise a competitor ships better extraction and your accountancy-firm customers churn. The AI feature isn't a strategic choice; it's a defensive one.

So they shipped. New homepage copy. New pricing tier (the AI-extraction tier costs more than the old plain-OCR tier). New marketing campaign.

This is normal SaaS behavior. The problem is that the marketing was aimed at solo founders too, who don't have the same workflow as accountancy firms and don't benefit from the feature.

Macro trend of AI in receipt SaaS launched in 2024-2025

The pitch: save time on data entry

The marketing copy is consistent.

"Stop manually entering line items into QuickBooks."

"AI extracts vendor, date, amount, line items, and tax breakdown automatically."

"Save 5 hours a month on data entry."

If you're an accountancy firm processing receipts for 50 small business clients, this pitch makes sense. You have a team of bookkeepers entering invoice data into accounting software all day. Cutting that work by 80% is real money.

If you're a solo founder, ask yourself: how many hours did I spend on data entry last month? For most of us, the answer is zero. We don't enter data anywhere. Our bank feed populates QuickBooks (if we use QuickBooks). Our Stripe dashboard shows our revenue. Our credit card statement shows our expenses.

The data is already in the systems we use. Receipts are the substantiation, not the data source.

The CPAs we talked to confirm this. They cross-reference the bank statement with PDFs. They don't type line items into a spreadsheet from scratch.

The "save 5 hours a month" pitch is real for some users. It's just not real for the solo-founder buyer the marketing reaches.

Pitch vs reality data entry

The reality: most solo founders don't do data entry

Walk me through your monthly bookkeeping. What does it look like?

For most solo founders, it looks like nothing. You don't reconcile your books monthly. You don't categorize transactions. You don't enter receipts into anything.

You log into Stripe to see this month's revenue. You glance at your bank statement once a quarter. You set aside a percentage for taxes. You hire a CPA for the actual return prep in March.

The bookkeeping work that AI receipt apps automate is work you weren't doing. The features save 5 hours a month for an accountancy firm with 50 clients. They save zero hours for a solo founder with 1 business.

Solo founders who do their own monthly books? Sure, the AI helps a little. But the time savings are usually 30 minutes a month, not 5 hours. And there's a cheaper way (export the bank feed; categorize via QuickBooks's built-in rules engine; never see a receipt during reconciliation).

Solo founders dont data entry

The math: GPU dollars vs solo-founder savings

AI extraction isn't free for the vendor. Every receipt processed costs them real GPU dollars - call it $0.005 to $0.05 per receipt depending on the model and the receipt complexity.

If a solo founder processes 250 receipts a year, the vendor's AI cost is $1 to $13 a year. The vendor wraps that in a subscription that charges $25 to $35 a month, or $300 to $420 a year.

The math: you're paying $300+ for $13 worth of AI. The other 95% of your subscription is paying for the SaaS overhead - servers, support, sales, free trial users.

This wouldn't be unreasonable if the AI was solving a real problem for you. It isn't, per the previous section.

Compare to AutoFileEmail's economics. We don't run AI. Our cost per email processed is roughly $0.0001 (storage and compute for moving an attachment from email to Drive). That's why we can be free for one inbox. There's no GPU bill to recover.

We also don't have a per-receipt fee, because we don't process receipts as individual high-value units. We move attachments. The sender domain logic is rule-based, not AI-based. Cheap, fast, deterministic.

GPU dollars vs solo savings

The privacy hit nobody mentions

Here's the part that gets overlooked.

When AI extracts your receipts, the AI has to read every receipt. That means every line item. Every vendor name. Every amount. Every business meal at every restaurant. Every Uber. Every flight.

Where does that data live after extraction? On the vendor's servers. Often in indexed form. Sometimes shared with sub-processors (the LLM API provider, in particular).

Read any receipt SaaS's data processing addendum carefully and you'll find:

"We may share your data with the following sub-processors: Google Cloud Platform, AWS, Anthropic (for AI processing), OpenAI (for AI processing), Pinecone (for vector search)..."

Each sub-processor is another set of servers your receipt data passes through. Each one has its own data retention policy. Each one is a potential breach surface.

For most expense data this isn't catastrophic. But "I bought ChatGPT Plus this month" is the kind of expense profile that, in aggregate across millions of users, reveals competitive intelligence (which AI products are growing), personal travel patterns, and business relationships.

We covered this in detail when we wrote about why we explicitly chose not to OCR. The TL;DR: every additional system that touches your receipt data is a system that can lose it.

AutoFileEmail's data path: email arrives at Gmail (Google has it), attachment is downloaded by us, attachment is uploaded to your Drive (Google has it again), our servers don't retain the file. The receipt content is never indexed, never extracted, never embedded for search.

No AI practice explanation

The counter-argument: AI does help large practices

To be fair, AI extraction isn't worthless. It's just worthless for the solo founder.

If you're a CPA managing 50 small business clients and trying to scale your practice, AI extraction is real time savings. Hundreds of receipts a week, multiplied across clients, adds up to dozens of hours a month. That's where the original Hubdoc/Dext business model lived.

The right answer in that scenario is: the CPA pays for the AI tool. They build it into their service price. Their clients (you) hand over PDFs.

This used to be how it worked. Hubdoc's accountancy-firm tier exists for exactly this. The clients don't pay; the firm pays. The firm benefits from the AI, the clients hand over PDFs in whatever format works.

Then receipt SaaS realized they could double-dip and started selling direct-to-consumer subscriptions to the same clients whose firms were already paying for the firm tier. That's the racket. The same OCR is being charged for twice - once to the CPA, once to you.

If your CPA wants OCR'd data for their workflow, they should pay for it. That's the strategic choice. You don't need to.

What "no AI" means in practice

AutoFileEmail doesn't run any AI on your receipts. Specifically:

No OCR.
No line-item extraction.
No vendor name normalization beyond the sender domain rule (which is regex, not AI).
No category guessing.
No anomaly detection ("you spent more than usual on AWS this month").
No GPT-powered search of your receipts.

What we do: file attachments by sender domain into a Drive folder. Done.

This is a deliberate choice. The cost of running AI on every receipt would force us into a per-receipt fee model and away from the free-for-one-inbox tier. It would also create the privacy and data-sharing surface area we just spent two sections explaining we don't want.

The bet is: the file is enough.

What no AI means in practice for receipt processing

When "the file is enough" breaks down

Honest moment. There are scenarios where you'd want OCR.

You're audited and the IRS specifically asks for line-item breakdowns of every meal expense.
You're managing reimbursements for a 50-person company and need to detect duplicate expense submissions.
You're a freelancer in a country with VAT/GST that requires line-item tracking for input-tax credit claims.
Your business has regulatory reporting requirements that mandate categorized expense data.

In any of those cases, you need OCR. AutoFileEmail isn't the right tool. Use Dext or Hubdoc, pay the subscription, accept the data-sharing tradeoffs.

For most solo founders, none of those apply. The IRS doesn't ask for line items unless they audit (rare, and they ask for the original PDF anyway). You don't have employees to manage. You're not in a VAT jurisdiction (or you have a separate tool for that already). Your filing requirements are: substantiate deductions per Pub 583.

For the actual filing requirement, the file is enough. AI doesn't add anything.

The bottom line

AI receipt extraction is a real feature with a real audience. That audience is accountancy firms processing high volumes of small-business receipts.

If you're a solo founder, you're not the audience. You're being marketed to because you have a credit card and the SaaS company has a sales target. The features don't solve a problem you have. They cost money you don't need to spend. They share data you didn't want to share.

AutoFileEmail's bet: file the receipts, don't read them. Free for one inbox. No AI bill to pass on, no privacy surface to extend, no per-receipt fee.

The future of receipt management for solo founders isn't smarter AI. It's a Drive folder that fills itself. We've been overengineering this category for a decade. Time to undershoot the spec on purpose.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/ai-reads-invoices-feature-in-search-of-problem/ai-receipt-reading-feature-search-problem-banner-987e4f07-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Receipt Retention Rules by Country (US, UK, Australia, Canada)]]></title>
            <link>https://autofile.email/blog/receipt-retention-rules-by-country</link>
            <guid isPermaLink="false">https://autofile.email/blog/receipt-retention-rules-by-country</guid>
            <pubDate>Tue, 07 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[How long do you actually need to keep tax receipts? IRS, HMRC, ATO, and CRA rules side by side, plus whether digital copies count.]]></description>
            <content:encoded><![CDATA[Receipt retention rules by country (US, UK, Australia, Canada) in Studio Ghibli style

It's a Tuesday in July. You're cleaning out a Drive folder from 2018. Five-year-old Stripe receipts. Should you delete them? Are you legally allowed to?

The honest answer is: it depends on what country's tax authority you answer to. And the rules are surprisingly different.

Most freelancers I know assume "seven years" because they heard it once. Some assume "forever" because deleting feels scary. Both are wrong in most cases.

Here is what each tax authority actually requires, with sources, in plain English.

Table of Contents

United States: IRS
United Kingdom: HMRC
Australia: ATO
Canada: CRA
Quick comparison table
What "adequate" actually means in practice
How AutoFileEmail handles all four jurisdictions
The "destroy after retention" knob
What about other countries
Why "start now, not at year 7"
TL;DR

United States: IRS

The IRS publishes its retention rules in Publication 583 and Topic 305. The short version:

3 years from the date you filed your return, or the due date of the return, whichever is later. This is the default for most filings.
6 years if you under-report gross income by more than 25%.
7 years if you're claiming a loss from worthless securities or a bad-debt deduction.
Indefinitely if you didn't file a return, or filed a fraudulent one.

Employment tax records: 4 years from the date the tax becomes due or is paid, whichever is later.

Most solo founders and freelancers fall under the 3-year rule. If you've been honest, filed on time, and don't have weird capital-loss claims, three years is the floor.

In practice, I keep mine for 7. The cost is zero (Drive folder), and "if I get audited late" is a real failure mode worth eliminating. But the IRS does not require 7. They require 3.

Digital copies? Yes, fully accepted. Per Rev. Proc. 97-22, electronic storage systems are valid as long as the system "ensures the integrity, accuracy, and reliability" of records and produces legible reproductions. PDFs in Drive meet that bar.

US IRS retention rules for receipts shown by a freelancer organizing documents

United Kingdom: HMRC

HMRC's rules are stricter on duration but well-defined.

Self-employed (sole traders, partnerships): keep records for 5 years after the 31 January submission deadline of the relevant tax year.
Limited companies: keep records for 6 years from the end of the financial year they relate to.
PAYE records: 3 years after the end of the tax year.

The 5-year clock for self-employed people is the one that surprises people. The 2024-25 tax year files on 31 January 2026. Records for 2024-25 must be kept until 31 January 2031. So you're effectively holding records for almost 6 years from when the expense actually happened.

If HMRC opens an enquiry, you keep records until the enquiry closes regardless of the deadline.

Source: GOV.UK Business records if you're self-employed.

Digital copies? Yes. HMRC accepts digital copies as long as they're complete, legible, and you can produce them on request. PDFs in cloud storage are explicitly fine.

UK HMRC records duration illustrated with a planner

Australia: ATO

The Australian Tax Office uses 5 years.

5 years from the date you lodge the relevant tax return. So if you lodge your 2025-26 return in October 2026, you keep records until October 2031.
If you're in a dispute with the ATO, the clock pauses until the dispute resolves.
Capital gains tax records: 5 years after the year in which the CGT event occurs (which can be far in the future from when you bought the asset).

Source: ATO record-keeping for business.

Digital copies? Yes, the ATO accepts electronic records explicitly. The requirements: records must be in English (or easily translated), kept for the full 5 years, and not altered or manipulated. A read-only PDF in Drive satisfies this.

The ATO has good plain-language guidance on this. Worth a read if you're operating in Australia: their position is essentially "we don't care about format, we care that the record exists and is unaltered."

Australia ATO record-keeping rules with a practical desk scene

Canada: CRA

Canada is the longest of the four major English-speaking jurisdictions.

6 years from the end of the tax year the records relate to. So 2024 records must be kept until the end of 2030.
If you file late, the 6 years runs from the date you filed.
For corporations, certain records (minute books, share registers) must be kept for the life of the corporation plus 2 years after dissolution.

Source: CRA: How long should you keep your books and records.

Digital copies? Yes. CRA's IC78-10R5 explicitly allows electronic records, with one important caveat: the records must be accessible and convertible to a readable format on request. PDFs in Drive qualify.

CRA can require records be kept in Canada or accessible from Canada. For sole proprietors, this usually isn't a practical issue because you can just access Drive from anywhere in Canada. For corporations or larger businesses, talk to your accountant.

Canada CRA retention duration illustrated with a Canadian desk setup

Quick comparison table

| Country | Authority | Default retention | Digital OK? |
|---------|-----------|-------------------|-------------|
| US | IRS | 3 years (6 or 7 in edge cases) | Yes |
| UK | HMRC | 5 years from 31 Jan deadline (self-employed) | Yes |
| Australia | ATO | 5 years from lodgement | Yes |
| Canada | CRA | 6 years from end of tax year | Yes |

Notice none of these say "forever." None of these say "you must keep paper." All four explicitly accept digital copies that are intact and readable.

What "adequate" actually means in practice

The bar is not "the IRS will be impressed by your filing system." The bar is "if asked, you can produce the document."

For all four countries, an adequate record is one that:

Identifies the vendor (who you paid)
Shows the date
Shows the amount
Is legible
Hasn't been altered

A PDF receipt in /AutoFileEmail/stripe.com/2024/03/ meets all five. The folder structure even pre-categorizes by vendor for you, which makes producing a specific receipt during an enquiry trivial: "Show me what you spent on Stripe in March 2024" becomes one folder click.

For more on what auditors actually want, see the 3 folders that survive an audit and what the IRS actually needs from your receipts.

How AutoFileEmail handles all four jurisdictions

AutoFileEmail files attachments into your Drive in the format /AutoFileEmail////. This works under every retention regime listed above because:

Files are immutable in your Drive. Drive's file IDs and modification timestamps function as a tamper-evident log. If you ever need to prove a record hasn't been altered, Drive's revision history does that work.
Your Drive is yours. AutoFileEmail uses the drive.file scope only - we can only see files in folders we created. We don't host your receipts on our servers; they live in your Google account.
Folder structure pre-organizes by tax year. When the CRA or HMRC asks for "tax year 2024," you produce one folder. Done.
No vendor lock-in. If you stop using AutoFileEmail tomorrow, the files stay in your Drive, in the same folder structure, for as long as you need them. There's no proprietary format. The PDFs are the PDFs your vendors sent.

This is why we don't have a "digital archive" feature you pay extra for. The archive is your Drive. We just put files in it correctly.

The "destroy after retention" knob

None of the four countries require you to keep records forever. Once the retention window passes, you can legally delete them.

Many people don't bother because storage is cheap. But if you care about reducing your data footprint - say, you're winding down a business or moving providers - you can clean out old years.

Drive makes this easy: select the year folder, move to trash. Empty trash. Done. Because AutoFileEmail's folder structure groups by year, deleting "everything older than 6 years" is a single delete.

If you're paranoid (some people are, especially in the EU under GDPR data minimization), this is a real option. See GDPR for one-person businesses for the privacy-focused take.

What about other countries

The four above cover most of our user base. A non-exhaustive sampler of others:

Germany: 10 years for tax-relevant records (Abgabenordnung Section 147).
France: 6 years for tax records, 10 years for accounting records.
Singapore: 5 years from the relevant year of assessment.
India: 8 years for income tax records (extended in some cases).
New Zealand: 7 years.

In every one of these jurisdictions, digital copies are accepted as long as they're legible and unaltered. The specifics vary; check your local tax authority's guidance.

Why "start now, not at year 7"

The biggest mistake I see is people who plan to "get organized for taxes" the month before they file. By then, every receipt from January to March is buried in Gmail, the Stripe ones are in a different inbox than the AWS ones, and reconstructing the year takes a full weekend.

If you turn on auto-filing in May 2026, your retention clock starts now. By the time the IRS, HMRC, ATO, or CRA could possibly ask, every receipt from this point forward is already filed in the right folder, with the right vendor name, in the right year.

Five years from now, when someone asks you for a 2026 invoice, you'll find it in 30 seconds.

The alternative is a panicked Gmail search starting at year 7.

TL;DR

US (IRS): 3 years default, 6 if you under-report 25%+, 7 for losses.
UK (HMRC): 5 years from 31 January submission deadline (self-employed).
Australia (ATO): 5 years from lodgement.
Canada (CRA): 6 years from end of tax year.
All four accept digital copies. PDFs in Drive qualify everywhere.
None require permanent retention; you can delete after the window expires.

Auto-filing today means you have a clean record by the time anyone could ask for it. AutoFileEmail is free for one inbox, works with Gmail and Drive today, and handles every retention regime above without any configuration.

We don't read your receipts. We just file them, in the right year, in the right folder, where every tax authority on this list will accept them.

If you're a freelancer juggling income across multiple jurisdictions or just want a system that works the same wherever you file, start here. Two minutes to connect, then you're done.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/receipt-retention-rules-by-country/receipt-retention-rules-by-country-ghibli-banner-2fe6c5cf-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Apple Wallet Receipts to Drive: A Workaround]]></title>
            <link>https://autofile.email/blog/apple-wallet-receipts-drive-workaround</link>
            <guid isPermaLink="false">https://autofile.email/blog/apple-wallet-receipts-drive-workaround</guid>
            <pubDate>Fri, 10 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Apple Wallet doesn't email PDF receipts for most transactions. Here's the workaround that gets most of them filed automatically.]]></description>
            <content:encoded><![CDATA[Apple Wallet receipts to drive: workaround for freelancers and taxes in a Studio Ghibli vibe

Your tap your iPhone at the coffee shop. Apple Pay lights up. Done.

Two days later you're hunting for the receipt for your books. Apple Wallet shows the transaction. There's no PDF. There's no email. There's just a row that says "Blue Bottle Coffee, $6.50, Tuesday."

For most Apple Pay transactions, that's all there is. Apple Pay isn't a receipt system. It's a payment method. The receipt - if there is one - is the merchant's responsibility.

This is the gap nobody talks about when they pitch Apple Pay as the future of payments.

Here's what you can actually do about it.

Table of Contents

What Apple Wallet stores vs. what you need
The Mercury / Brex case (best in class)
What about manual entry apps (Wallet, Numbers, etc.)
The gap we're honest about
A practical setup for an Apple-Pay-heavy freelancer
TL;DR

What Apple Wallet stores vs. what you need

Apple Wallet stores enough to remind you a transaction happened: merchant name, amount, date, the last 4 digits of the card. That's it.

What your accountant or the IRS wants:

Vendor name (full legal name, not just the merchant brand)
Vendor address or tax ID
Itemized line items (or at least a category)
Amount with tax broken out
Payment method
A document you can produce on request

The Wallet entry has 1, 4 (no tax breakdown), and 5. It's missing 2, 3, and 6. That's why "I'll just take a screenshot of Wallet" doesn't survive an audit. The screenshot isn't a receipt. It's a transaction log entry.

The IRS wants:

A vendor name that matches your records
Tax ID or address for the vendor
Itemized details or categories
Tax amounts shown
The payment method clearly indicated
A document you can produce on request

The IRS page linked above explains the specifics.

The screenshot-and-AirDrop workflow (and why it sucks)

Most freelancers I know run this workflow:

Open Wallet on phone.
Find the transaction.
Tap to expand.
Screenshot.
AirDrop to Mac.
Save into a "receipts" folder on Desktop.
Maybe rename. Maybe.
Forget which folder it went into.

This works for one or two transactions. At twenty per month, it falls apart by week two.

It also produces screenshots, not receipts. A screenshot of "Blue Bottle Coffee $6.50" is barely better than a Wallet screenshot - your accountant has no more information than they had before.

The transactions that DO email a receipt

Some Apple Pay transactions produce a real PDF receipt in your inbox. Here's the rough taxonomy.

Always emails a real receipt:

Mercury (business banking) - sends an itemized receipt for every Mercury Card Apple Pay transaction.
Brex - similar; itemized receipts in your inbox per transaction.
Apple Store / App Store / Apple subscriptions - emails a receipt to your Apple ID.
Stripe-powered checkouts (Stripe-hosted, Stripe Tap to Pay) - the merchant can configure email receipts and most do by default.
Square sellers - if the merchant has email-receipts on (default for new Square accounts) you'll get a receipt to whatever email the merchant has on file or the email you tap-confirm at checkout.
Shopify-powered POS - same pattern as Square.

Sometimes emails a receipt:

Toast / Clover / SumUp / Lightspeed POS - merchant-configurable. Many opt-in, some don't.
Independent retail running their own POS or merchant account.
Subscription services (Netflix, Spotify, Substack) - usually email receipts, but to your account-on-file email which may not be your AutoFileEmail inbox.

Almost never emails a receipt:

Tap-and-go transit (NYC OMNY, London TfL, BART Clipper) - by design, no email receipts. You can usually pull statements from the transit authority's web portal, but no per-tap PDF.
Vending machines.
Parking meters and small kiosks.
Most in-store retail running legacy POS that doesn't have email-receipt configured.

This is the honest gap. AutoFileEmail can only file receipts that arrive as email attachments. If a receipt was never emailed, no app on your phone is going to make one materialize.

The workaround: route Apple Pay receipts through your AutoFileEmail inbox

Here's the move. Most merchants who do email receipts send them to the email associated with your Apple Pay payment method, which is usually your Apple ID email by default.

If your Apple ID is you@gmail.com and that's your AutoFileEmail-connected inbox, you're done; receipts route correctly.

If your Apple ID is on iCloud and your AutoFileEmail inbox is different, you have two options:

Option 1: Set up email forwarding from iCloud Mail

In iCloud Mail settings, set a forwarding rule: forward all incoming mail to your AutoFileEmail-connected Gmail. Receipts arrive at iCloud, get forwarded, get filed.

The cost: every email goes through forwarding, including non-receipts. But Apple Wallet receipts get into your filing system.

Option 2: Update your default receipt email at point-of-sale

When checkout terminals ask "Email receipt to?" enter your AutoFileEmail-connected inbox once. Most modern POS systems remember this for that merchant. Square, Shopify, Toast all save the email per device for re-use.

Tedious the first time at each merchant. Permanent after.

The Mercury / Brex case (best in class)

If you have a business card from Mercury, Brex, or similar fintech-issued cards, your Apple Pay setup is essentially solved.

Mercury sends an email receipt for every transaction with the card, including Apple Pay transactions. Brex does the same. Send all of them to your AutoFileEmail-connected inbox.

The result: every business expense charged to that card lands in your Drive, filed under /AutoFileEmail/mercury.com/2026/07/ (or brex.com), automatically, no action.

This is genuinely the best receipt-management setup possible for solo founders. The card itself is the OCR layer. Apple Pay just becomes the input device.

If you're not on Mercury or Brex, this is one of the under-rated reasons to consider switching cards.

What about manual entry apps (Wallet, Numbers, etc.)

Apple's own Wallet has no export-to-Drive feature. You can't bulk-export transactions to PDF. The Numbers/Excel-based "I'll just enter every Wallet transaction by hand" approach is what the entire receipt-app industry was built to replace, and for good reason: nobody does it consistently.

If you're going to enter transactions by hand, you've already lost the productivity battle. The reason auto-filing exists is to make "the act of getting a receipt" identical to "the receipt being filed."

For the same reason we don't read your receipts (see why we don't OCR), we also don't manually log transactions for you. We let the merchant do their part (email a receipt) and we automate the next step (file it).

The gap we're honest about

The transit / vending / cash-only-but-Apple-Pay-too gap is real. AutoFileEmail does not solve it.

For these:

Transit: download a monthly statement from your transit authority's portal once a month, email it to your AutoFileEmail inbox. The "vendor" becomes mta.info or similar, filed correctly.
Tipping kiosks, parking meters, vending: if you need them for taxes, photograph the receipt (if there is one) and email it to yourself.
Cash-with-Apple-Pay-fallback: doesn't apply to most freelancers because you'd be using Apple Pay, not cash.

This isn't a weakness of email-based filing; it's a structural fact about Apple Pay. Some transactions never produce a paper trail. The fix is at the payment layer, not at the filing layer.

A practical setup for an Apple-Pay-heavy freelancer

If you live on Apple Pay, here's the ideal stack:

Business card on Mercury or Brex. Every charge generates an email receipt automatically.
Personal Apple ID receipts route to your AutoFileEmail inbox. Either via forwarding or by changing your Apple ID email.
AutoFileEmail watches that inbox and files everything to /AutoFileEmail////.
At physical merchants, answer "email receipt?" with your AutoFileEmail-connected address.
For transit and vending, monthly statements emailed to yourself.

Setup time: maybe 15 minutes once. After that, ~95% of Apple Pay receipts file themselves.

The remaining 5% you handle once a month by emailing yourself a statement. That's the tax-time work that used to take a weekend, now it's a 10-minute monthly habit.

TL;DR

Apple Wallet stores transactions, not receipts. Most Apple Pay charges don't produce a PDF.
The transactions that DO email a receipt (Mercury, Brex, Apple subscriptions, Stripe/Square/Shopify-powered checkouts) can be auto-filed normally.
Set Wallet's associated email - or your Apple ID email - to your AutoFileEmail-connected inbox so receipts route there.
The gap (transit, vending, cash-only POS) won't be closed by any app; download monthly statements as a workaround.
Mercury/Brex card + AutoFileEmail = the cleanest possible Apple-Pay-heavy setup.

AutoFileEmail is free for one inbox, works with Gmail today, and handles Apple-Pay-derived email receipts without any extra configuration. Connect Gmail and Drive in 2 minutes; from there, every receipt that does arrive by email lands in the right folder automatically.

For the broader Drive-side setup and integrations, see our integrations page.

We don't read your receipts. We just file the ones the merchant sends you. That's the whole thing.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/apple-wallet-receipts-drive-workaround/apple-wallet-receipts-workaround-banner-f3ec45c3-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Why We'll Never Charge Per Email Scanned]]></title>
            <link>https://autofile.email/blog/never-charge-per-email-scanned</link>
            <guid isPermaLink="false">https://autofile.email/blog/never-charge-per-email-scanned</guid>
            <pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Hubdoc and Dext meter per receipt because OCR costs scale linearly. We don't OCR, so we can stay free for one inbox forever. Here's the math.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner about OCR pricing with no per-email metering

Every receipt-management tool on the market eventually meters you.

Hubdoc bundles you into a QuickBooks plan that climbs with usage. Dext has tiers based on document count. AutoEntry is literally per-document above the entry tier. Even Expensify - the supposedly cheap one - caps submissions and charges per active user.

The pattern is universal. The reason is universal too: OCR has a per-document GPU cost, and per-document cost forces per-document pricing.

We do not OCR. So we will never meter you. This is not generosity. It's just a different cost structure.

Here's the math.

Table of Contents

Why every OCR-based receipt app meters
Why we can be free for one inbox forever
So what do we charge for
Forward filing is steady-state pennies
"But what about your servers / engineers / VC?"
Why cap exists at all
The "no per-email metering" version of the contract
Why this isn't generosity
TL;DR

Why every OCR-based receipt app meters

Modern OCR runs on GPUs. Per page, a high-quality OCR pass costs somewhere between half a cent and three cents in raw cloud compute, depending on the engine (Google Document AI, Amazon Textract, Microsoft Form Recognizer, Tesseract on managed GPUs).

Add the SaaS company's overhead - storage, indexing, search, the dashboards, support - and the marginal cost of "process one more receipt" lands around 5 to 12 cents per document.

If you process 500 receipts a year on Hubdoc, that's $25 to $60 in compute costs alone. Add gross margin (usually 75%+), and you can back out why the entry tier is $35 a month: they need that revenue to cover the compute on the heaviest users while still paying for the rest of the business.

This is honest accounting. It's not predatory. It's just what OCR-as-a-service looks like.

Infographic-style illustration showing OCR-based receipt apps meter pricing per document with a cost graph

The consequence is that every OCR app eventually faces a choice:

Cap submissions. Free or cheap tier with a hard limit (Expensify's "active user" model).
Tier by document count. Pay more as you process more (Dext, AutoEntry).
Bundle into a bigger product. Make OCR a feature of accounting software you already pay for (Hubdoc inside QuickBooks).

All three paths route to the same place: you pay more as you do more. Per-receipt pricing is the inevitable shape of an OCR-based business.

Why we can be free for one inbox forever

We don't OCR. So our cost structure is wildly different.

What does AutoFileEmail actually do per filed attachment?

One Gmail API call to fetch the message and attachment.
One Drive API call to upload the file into the right folder.
Two database writes (one to mark the message processed, one to record the filed document).

That's it. No OCR. No image processing. No structured-data extraction. No search index.

Cost per filing? Roughly:

Gmail API call: included in Google's free tier up to 250 quota units per second per user. We use ~5 quota units per filed attachment. Effectively free at our scale.
Drive API call: same story; included in Google's free tier.
Database writes: small fractions of a cent on Supabase.
Our compute: a Cloudflare Worker invocation, ~$0.50 per million invocations.

Round numbers: we pay something like 0.001 to 0.005 cents per filed attachment. Three or four orders of magnitude cheaper than OCR.

500 attachments a year for one user costs us maybe 2 cents in marginal cost.

At 2 cents a year, "free" is not a marketing concession. It's just the actual cost.

No OCR forever: single inbox concept with a celebratory scene

So what do we charge for

Two things, both honest.

Backfill Packs ($29 / $59 / $99, one-time, no refunds.)

Backfill is the bursty part. When a user signs up and asks us to file 3 years of historical email, that's potentially 30,000 messages processed in an afternoon. Even though our per-message cost is tiny, the Gmail API has rate limits and quota costs that show up at this scale, plus we need to allocate compute slots to keep the user's queue moving without blocking other users.

The Tax Year Pack ($29) covers ~1 year of history. The 3-Year Pack ($59) covers up to 3 years. The Lifetime Pack ($99) covers everything in your inbox up to a 50,000-email cap.

That cap is honest fair use, not a meter. We're not going to hit you with overage charges if you blow past it; we'd rather have a hard stop you can predict than a per-email creep that surprises you.

For the full breakdown of when each Pack makes sense, see backfilling 3 years of receipts in an afternoon.

Pro tier ($14.99/mo or $149/yr) - coming post-MVP.

When we ship multi-inbox support, the value-add justifies a real subscription. 5 inboxes, all clouds, advanced filtering. The 1-inbox tier stays free.

That's the whole price card. No per-receipt fee, no overage, no document-count tier, no "active user" cap.

Forward filing is steady-state pennies

The day-to-day "new email arrives, file it" workflow is the cheapest part of our infrastructure. Every 30 seconds we poll your connected inbox; if there's a new attachment, we file it.

Per user per month: maybe 50,000 polling calls (mostly returning "no new messages") and maybe 50 actual filings. The polling is essentially free; the filings are essentially free.

For one user that's under $0.01 a month in marginal infrastructure cost. For 10,000 users? Around $100. For 100,000 users? Around $1000.

This is why "free for one inbox forever" composes. The unit economics aren't strained by free users. The fixed costs (engineering, support, marketing) get amortized across paying users (Backfill Packs, eventual Pro). Free users don't break the model; they're just cheap users.

Compare to Hubdoc, where every free user would cost them real GPU dollars on every receipt. They literally cannot offer "free for one user forever." We literally can.

But what about your servers / engineers / VC?

"But what about your servers / engineers / VC?"

Reasonable question. Here's the answer.

Servers: Cloudflare Workers + Supabase. Total monthly cost at our current load is under $100. Storage is essentially zero because we don't store the PDFs - they live in your Drive.

Engineers: small team. Lifestyle business, not a VC growth-at-all-costs play. Our ramp is 2-3 years to sustainability via Backfill Packs and eventual Pro subscriptions, not 18 months to Series A.

VC: none. No pressure to push pricing or features that would compromise the "we don't read your stuff" contract.

This last one matters. A lot of "free forever" pitches from VC-backed startups end with the company running out of runway and either jacking up prices, monetizing your data, or shutting down. We're optimizing for none of those failure modes.

The pricing model has to actually work without funny business. Ours does because the cost structure is structurally different from OCR-based competitors. If we ever drift toward OCR, the structural advantage disappears and the pricing shifts. So we won't drift. The architecture is the moat.

Why we can be free for one inbox forever

Why cap exists at all

The Lifetime Pack has a 50,000-email cap. People sometimes ask why.

It's there for one reason: protecting steady-state economics from the long-tail "I have 17 years of email and want all of it filed" user. That user exists. They're rare, but at zero variable cost we'd quietly subsidize them forever.

50,000 emails covers basically everyone. Mid-size freelancer with 10 years of inbox history? 5,000 receipts. Heavy SaaS founder with vendor sprawl? 15,000. The cap is there to bound the worst case, not to extract money on the median.

If you somehow hit 50,000 and need more, email us. We'll figure something out. There's no overage charge.

Cap threshold illustrated as a 50,000-email limit barrier

The "no per-email metering" version of the contract

Here's what "we don't meter" actually means in practice:

Connect 1 inbox - free, forever.
Forward filing of new attachments - free, forever, no count cap.
Drive folder structure - free, no folder cap.
30-day historical preview on signup - free.
Backfill beyond 30 days - one-time Backfill Pack.
5 inboxes (when Pro ships) - $14.99/mo or $149/yr, fixed.

That's the entire pricing surface. There is no number-of-receipts variable in any of those line items. We have no API endpoint that increments a per-user receipt counter for billing purposes.

For the side-by-side with the OCR-everything tools, see Hubdoc vs us. The price differences are not subtle once you actually do the math at 500 receipts a year.

The no per-email metering contract

Why this isn't generosity

Founders sometimes pitch "free forever" tiers as a generosity flex. We don't.

Free for one inbox is what the cost structure naturally allows. We'd be price-gouging if we charged $5/mo for the 1-inbox tier when the marginal cost is fractions of a cent. The pricing reflects the architecture; the architecture reflects the philosophy ("we don't read your stuff"); the philosophy is the product.

OCR costs money. We don't OCR. So we don't charge for the thing we don't do.

That's it.

If we ever started OCR'ing - even quietly - the cost structure would flip and we'd have to meter. Which is one of the strongest reasons we'll stay anti-OCR forever: meter-by-receipt is bad UX, bad privacy, and we don't want to be there.

TL;DR recap board summarizing no per-receipt pricing

TL;DR

Per-receipt pricing exists because OCR has per-receipt GPU costs.
We don't OCR, so per-receipt costs don't exist for us.
1 inbox + forward filing = free, forever, no caps.
Backfill Packs ($29 / $59 / $99) cover the bursty one-time backfill load.
Pro ($14.99/mo, post-MVP) covers multi-inbox.
50,000-email Lifetime cap is honest fair use, not a meter.
This isn't generosity, it's just the architecture.

Free is sustainable when reading isn't the product. AutoFileEmail is free for one inbox at autofile.email. Connect Gmail and Drive, walk away. No GPU bill, no per-receipt counter, no overage email at the end of the month.

We don't read your receipts. We just file them.

TL;DR recap board summarizing no per-receipt pricing
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/never-charge-per-email-scanned/why-well-never-charge-per-email-scanned-banner-27a17897-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[iCloud Mail + iCloud Drive: The Missing Automation]]></title>
            <link>https://autofile.email/blog/icloud-mail-drive-missing-automation</link>
            <guid isPermaLink="false">https://autofile.email/blog/icloud-mail-drive-missing-automation</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[There's no built-in way to file iCloud Mail attachments to iCloud Drive automatically. Here's why, and a practical workaround using Gmail bridging.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for iCloud automation article with warm pastels

You're an Apple person.

Your email is you@icloud.com. Your files live in iCloud Drive. Your phone, laptop, watch, all wired into iCloud. You haven't touched a Google product on purpose in years.

Then you sit down to set up auto-filing for receipts and discover that there is, essentially, no way to automatically save iCloud Mail attachments to iCloud Drive.

No, really. Try to Google this. You'll find a dozen forum threads ending with "I gave up and used Hazel" or "I just do it manually now."

This article is about why that gap exists, what the half-workarounds are, and the actual fix.

Table of Contents

Why iCloud Mail and iCloud Drive don't talk to each other
The Mail.app + AppleScript route (fragile but possible)
The Shortcuts route (limited)
The Hazel route (Mac-only, post-download)
The third-party app route (most are sketchy)
The "iCloud Drive as destination" status
The minimum-fragile setup for an Apple-first freelancer
The bigger picture
TL;DR
The pivot: what AutoFileEmail does (and where it lands)

Why iCloud Mail and iCloud Drive don't talk to each other

This is the structural reason none of this works the way you'd hope.

iCloud Mail has no server-side rules engine. Gmail has filters that run on Google's servers, 24/7, regardless of whether you're logged in. iCloud Mail does not. The "rules" feature in macOS Mail.app is a client-side feature - it requires Mail.app to be running on your Mac for any rule to fire. If your laptop is closed, no rules run.

For unattended automation - the whole point of "auto-file my receipts" - this is fatal. Your receipts arrive at 3am Tuesday. Your Mac is asleep. Nothing happens. When you open the Mac on Wednesday, the rule fires retroactively for messages still in the inbox, but if you'd already moved them on iPhone, the rule never sees them.

iCloud Drive has no public API for third-party automation. Apple does not publish an iCloud Drive API. There's no equivalent of googleapis.com/drive/v3 you can call from a server. The only "automation" surface is:

The Files app on iOS (manual moves, Shortcuts integration).
The Finder on macOS (manual or AppleScript).
iCloud for Windows (sync only).

That's it. No webhook. No "watch folder for new files." No "drop a file in this folder from a third-party server."

Apple has explicitly chosen not to be a platform for third-party automation here. That's their right. It's also why the workflows below are all flavors of "fragile."

The Mail.app + AppleScript route (fragile but possible)

This is what serious Apple users have been doing for a decade.

Setup:

Mac that stays awake (sleep disabled, or at least lid-open with caffeinate running).
Mail.app installed and running.
Mail.app rule: "When attachment received from sender X, run AppleScript Y."
AppleScript: extract attachment, save to specific iCloud Drive folder, set name to -.pdf.

It works. Sort of. The failure modes:

Mac sleeps: rules don't fire.
Mail.app crashes: rules don't fire until you reopen.
macOS update: AppleScript permissions revoked, you have to re-grant.
Multi-device race condition: if you read the email on iPhone first, the message is marked read by the time Mail.app on Mac sees it, which can prevent some rules from firing depending on the trigger condition.
Sender variations: every receipt vendor needs its own rule. AWS sends from aws-receipts@aws.com, sometimes from no-reply@amazon.com. Two rules per vendor, or one rule per regex.

You also need a Mac that is genuinely always-on. Most freelancers don't have that. Their MacBook closes at the end of the day.

Mac setup with Mail.app rules and AppleScript saving attachments to iCloud Drive

The Shortcuts route (limited)

Apple's Shortcuts app added Mail integration, and you can build "save attachment from email to Files" shortcuts. Triggers include:

Manual run (you tap the shortcut).
Time of day (8am every weekday).
When connected to a specific Wi-Fi.

What's missing: an "on email arrival" trigger. Shortcuts cannot fire when a new email arrives. The closest you can get is "every hour, check for new emails from \list of vendors] and save attachments." Battery cost is real, and the fanout to specific vendors becomes its own maintenance burden.

Shortcuts also has no programmatic way to organize by sender domain. You'd have to hand-code a Shortcut per vendor or build one giant shortcut with branching logic. Possible. Painful.

iPhone and Mac showing Shortcuts automation with limited triggers

The Hazel route (Mac-only, post-download)

Hazel is the legendary Mac automation tool. It watches folders and runs rules when files appear.

The pattern: configure Mail.app to download all attachments to a specific Mac folder. Hazel watches that folder. When a PDF appears, Hazel parses the filename or sender (from saved metadata), moves it to the right iCloud Drive folder.

This works. Hazel is genuinely good. But:

You're back to needing Mail.app running on a Mac.
"Download all attachments" is a separate Mail.app config that has to stay enabled.
Hazel runs locally on the Mac, which means while you're traveling with iPad-only, nothing files.
Hazel costs $42 once. Worth it if you're staying on this stack, but it's another tool.

Hazel is the most-recommended workaround in r/macapps for this exact problem, which tells you how thin the alternatives are.

Hazel automations watching a folder on Mac, moving files to iCloud Drive

The third-party app route (most are sketchy)

Search the App Store for "iCloud receipts" and you'll find a handful of apps that promise to file iCloud Mail attachments. Most of them either:

Require you to grant your iCloud password, which violates Apple's TOS and risks your account getting locked.
Run only on-device, with the same "your iPhone has to be plugged in and unlocked" constraint.
Are abandoned. Last update 2021.

A few legit ones use [app-specific passwords and IMAP, which is the cleanest path technically but still requires you to trust a third-party app with mailbox access. The privacy and security review on these is uneven.

For comparison with the broader receipt-app market, see receipt apps and what they do with your data, ranked.

AutoFileEmail pivots from iCloud to Google Drive for automated filing

The "iCloud Drive as destination" status

This isn't on our roadmap. Not because we don't want to ship it - we'd love to - but because there is no public iCloud Drive API for server-side writes from a third party. Apple has consistently chosen not to expose one.

If Apple ever ships a CloudKit-based public API for Drive writes, we'd revisit. Until then, the destination is Google Drive.

People sometimes ask "what about syncing the Google Drive folder back into iCloud Drive?" You can do this with iCloud's external storage providers (Drive shows up in Files app), or with rclone on a Mac, or with Hazel watching the synced Drive folder. All workable. None as clean as native.

The minimum-fragile setup for an Apple-first freelancer

If you live on iCloud and want auto-filing today:

Option 1 (recommended): AutoFileEmail with iCloud IMAP + Google Drive destination (when iCloud IMAP ships). Add Google Drive as an external location in Files.app on iOS so receipts appear alongside iCloud.

Option 2 (today, no Google): Hazel + Mail.app + always-on Mac. ~$42 one-time, plus the Mac power bill, plus ongoing maintenance.

Option 3 (manual): AirDrop receipts from iPhone to Mac, drag into iCloud Drive folders. Sustainable for ~10 receipts a month, falls apart above that.

Most people I know who tried option 2 ended up at option 1 within a year because the Mac-always-on requirement just doesn't fit a real life.

The bigger picture

The iCloud Mail / iCloud Drive automation gap is one of the more striking examples of Apple's "we don't open APIs to third parties" philosophy producing a real user-facing problem. It's not a thing they screwed up. It's a thing they decided.

If you're committed to the Apple ecosystem and want auto-filing of receipts, you're going to be making a tradeoff one way or another:

Either you accept that automation needs an always-on Mac (Mail.app + Hazel).
Or you accept that the destination is Google Drive (AutoFileEmail).
Or you do it manually.

There's no fourth option. Anyone telling you otherwise is hand-waving.

For more on the broader integration roadmap and what's working today, see our integrations page.

TL;DR

iCloud Mail has no server-side rules engine; rules need Mail.app open to fire.
iCloud Drive has no public third-party write API.
The native automation routes (Mail.app + AppleScript, Shortcuts, Hazel) all require an always-on Mac.
AutoFileEmail will support iCloud via IMAP (coming soon), with Google Drive as the destination.
iCloud Drive as destination is structurally not possible for any third-party server-side automation.
The "Google Drive in Files.app via external location" trick gives you the appearance of native iCloud filing, with actual automation underneath.

If you're tired of doing this manually, start with AutoFileEmail's free tier (Gmail + Drive today, iCloud IMAP next). One inbox, free forever, no per-receipt fees.

We don't read your receipts. We just file them. Even when iCloud refuses to.

Illustration showing iCloud Mail and iCloud Drive separated by a communication gap

The pivot: what AutoFileEmail does (and where it lands)

AutoFileEmail will support iCloud Mail via IMAP using app-specific passwords (coming soon - mark roadmap, Gmail+Drive ships first).

What that looks like:

Generate an app-specific password on appleid.apple.com.
Connect AutoFileEmail to your iCloud inbox via IMAP using that password.
AutoFileEmail polls your iCloud inbox every 30 seconds for new attachments.
Files them to your Google Drive in /AutoFileEmail////.

The destination is Google Drive, not iCloud Drive.

This is the part that's going to bother some people, and it should be acknowledged directly: there is no public API to write to iCloud Drive from a third-party server. We can't ship that, and neither can anyone else. The only way to file to iCloud Drive automatically is via on-Mac tools (Mail.app, Hazel, Shortcuts).

Google Drive as the destination has actual benefits even for Apple-first users:

Files are accessible from any device including your iPhone.
iCloud Drive can add Google Drive as an external location so files appear in your Files app alongside iCloud.
The Drive drive.file scope means we can only see folders we created. Same privacy posture as iCloud.
All four tax authorities (IRS, HMRC, ATO, CRA) accept PDFs in Drive. See retention rules by country.

The honest tradeoff is: you get full automation, in exchange for the destination being Google Drive instead of iCloud Drive. For most people that's an acceptable trade. For purists, it isn't.

AutoFileEmail pivots from iCloud to Google Drive for automated filing

The "iCloud Drive as destination" status

This isn't on our roadmap. Not because we don't want to ship it - we'd love to - but because there is no public iCloud Drive API for server-side writes from a third party. Apple has consistently chosen not to expose one.

If Apple ever ships a CloudKit-based public API for Drive writes, we'd revisit. Until then, the destination is Google Drive.

People sometimes ask "what about syncing the Google Drive folder back into iCloud Drive?" You can do this with iCloud's external storage providers (Drive shows up in Files app), or with rclone on a Mac, or with Hazel watching the synced Drive folder. All workable. None as clean as native.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/icloud-mail-drive-missing-automation/icloud-mail-missing-automation-banner-e4dbbc34-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Outlook + OneDrive: The Freelancer's Filing Setup]]></title>
            <link>https://autofile.email/blog/outlook-onedrive-freelancer-filing-setup</link>
            <guid isPermaLink="false">https://autofile.email/blog/outlook-onedrive-freelancer-filing-setup</guid>
            <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Auto-file Outlook attachments into OneDrive by vendor and date. Two OAuth screens, no Power Automate, no custom expressions - here's the live setup guide.]]></description>
            <content:encoded><![CDATA[Studio Ghibli-inspired banner for Outlook + OneDrive freelancer filing setup

You're on Microsoft. Outlook for email, OneDrive for files, maybe a Microsoft 365 Business plan tying it all together. You like it. You've been on it for years.

Now you want the same thing every Gmail+Drive freelancer is doing: email attachments auto-filed into folders so tax time isn't a search-bar emergency.

Good news. As of this week, AutoFileEmail's Outlook + OneDrive integration is live. No Power Automate flow. No custom expressions. No 750-action daily ceiling. Two OAuth screens and you're done.

This is the working setup guide. End to end, what you click, where the files land, and the M365 admin gotchas to know about before you start.

Table of Contents

The 90-second version
What's different from a Gmail+Drive setup
Step one: connect Outlook
Step two: connect OneDrive
Where your files actually appear in OneDrive
M365 work accounts: the admin consent layer
How incremental consent will work for Pro
Why we're not just shipping a Power Automate template
The freelancer-on-Outlook playbook
TL;DR

The 90-second version

Sign up at autofile.email. In onboarding:

Click "Connect Outlook." Microsoft consent screen. Approve Mail.Read.
Click "Connect OneDrive." Second consent screen. Approve "Have full access to the application's folder."
AutoFileEmail starts polling your inbox every 30 seconds.
New attachments file into /Apps/AutoFileEmail/{vendor-domain}/{YYYY}/{MM}/ in your OneDrive.

That's it. No flows, no expressions, no per-action metering. The first 30 days of historical mail also get backfilled automatically as a free preview, so you'll see receipts populate within a few minutes of finishing onboarding.

If your inbox is at a Microsoft 365 work account and your IT department blocks third-party apps, skip ahead to the admin-consent section. If you're on a personal outlook.com / hotmail.com / live.com address, you can stop reading the warnings and just connect.

Freelancer onboarding flow for Outlook and OneDrive in a Studio Ghibli setting

What's different from a Gmail+Drive setup

Functionally? Almost nothing. Same dashboard, same activity log, same {vendor-domain}/{YYYY}/{MM}/ folder layout, same dedup logic.

The two real differences are cosmetic and live in OneDrive itself:

Files land under /Apps/AutoFileEmail/, not at the root. Microsoft's "App folder" mode for OneDrive sandboxes us. We can read and write inside that folder. We cannot see anything outside it. Your family photos, your work docs, your Documents folder full of half-finished pitch decks - invisible to us. We literally cannot list them via the Graph API. Drive's drive.file scope works the same way (we only see files we created), but OneDrive surfaces the sandbox more visibly with that /Apps/ prefix.

Outlook consent reads "Mail.Read." Drive's read-mail equivalent for Gmail says "Read all your email." Microsoft's wording is the same shape, slightly less alarming. Same access either way: we read message metadata and download attachments. We don't reply, we don't forward, we don't mark anything as read.

If you've already got a Gmail+Drive setup running and you're adding Outlook+OneDrive on Pro (5 inboxes, $14.99/mo, coming soon), the second pair just slots in. One activity log, both inboxes filing into their respective clouds.

Outlook connection consent scene in a warm Studio Ghibli-inspired setup

Step one: connect Outlook

In onboarding, after the Drive folder bootstrap step, you'll see a "Connect inbox" screen with three tiles: Gmail, Outlook, IMAP.

Click Outlook.

A Microsoft sign-in window opens. You sign in with the account you want filed - personal Microsoft (outlook.com, hotmail.com, live.com, msn.com) or your M365 work account (yourname@yourcompany.com). The consent screen lists exactly one permission:

Mail.Read - "Read your mail"

That's the entire scope. We don't ask for Mail.Send, we don't ask for Mail.ReadWrite, we don't ask for contacts, calendars, or anything else. The whole point of this product is filing attachments. We need to read mail. That's it.

Click Accept. The window closes. Onboarding shows a green checkmark next to "Outlook connected" and the email address.

If Outlook 365 with two-factor auth nags you, that's normal - approve the push or enter the code, then click Accept on the consent screen. Connection succeeds.

OneDrive connection consent with app folder scope in a gentle Studio Ghibli scene

Step two: connect OneDrive

Next screen. "Connect cloud storage." Three tiles: Google Drive, OneDrive, Dropbox.

Click OneDrive.

Second Microsoft window. Same account login (or sometimes it auto-fills). The consent screen this time lists:

Files.ReadWrite.AppFolder - "Have full access to the application's folder"
User.Read - "Read your profile" (used for auth, nothing else)

Files.ReadWrite.AppFolder is the narrowest OneDrive scope Microsoft offers. Translated: we can create, read, update, and delete files inside /Apps/AutoFileEmail/. We have zero access to anything else in your OneDrive. The Graph API will refuse if we try.

Click Accept. The window closes. Onboarding shows the OneDrive folder location: /Apps/AutoFileEmail/. AutoFileEmail kicks off the 30-day historical preview backfill in the background.

You're done. Onboarding hands you off to the dashboard.

OneDrive filing structure inside AppFolder shown in a Studio Ghibli vibe

Where your files actually appear in OneDrive

Open OneDrive in your browser. Click "My files" in the left nav.

Scroll down (or look for the "Apps" folder). Inside Apps, you'll see "AutoFileEmail." That's our folder. We're the only thing that writes to it.

Inside /Apps/AutoFileEmail/, the structure looks like this once you've got a few vendors filed:

/Apps/AutoFileEmail/
  amazon.com/
    2026/
      04/
      05/
  stripe.com/
    2026/
      04/
        2026-04-14-invoice.pdf
        2026-04-28-payout-report.pdf
      05/
  notion.so/
    2026/
      05/
  digitalocean.com/
    2026/
      05/

One folder per registrable sender domain. Subfolders by year, then month. Files keep their original names, prefixed with the email date so they sort cleanly inside the month folder.

This is the same layout used by the Gmail+Drive flow. If you ever switch clouds, your accountant doesn't have to learn anything new.

OneDrive AppFolder filing structure shown in a browser, Studio Ghibli vibe

M365 work accounts: the admin consent layer

If you're on a personal Microsoft account, skip this section.

If you're connecting an M365 work account and your tenant restricts third-party apps (most enterprise tenants do, plenty of small-business ones don't), the consent screen will say "Approval required" and the connection will fail.

Two paths forward.

Option 1: Tenant-wide admin consent. Send your IT admin a one-line ask: "Please grant tenant consent for AutoFileEmail at https://login.microsoftonline.com//adminconsent?client_id=." Once approved, any user in your org can connect without further IT involvement. The scopes IT will see are exactly the two listed above (Mail.Read and Files.ReadWrite.AppFolder), which is narrower than Hubdoc, narrower than Zapier, narrower than Power Automate's broad connectors. IT teams that scrutinize this rarely push back because the footprint is genuinely small.

Option 2: Per-user admin consent. If IT doesn't want to grant tenant-wide access, they can grant just-you consent for your specific account. Lower-stakes ask. Same outcome for you.

If you ARE the IT admin (solo founder running a single-user M365 tenant), the consent screen just adds one extra "Consent on behalf of your organization" checkbox. Tick it. Done.

For a comparison of how this scope footprint stacks up against the alternatives, see the OneDrive folder structure your accountant actually wants.

M365 admin consent flow scene in a friendly Studio Ghibli office

How incremental consent will work for Pro

Right now, free tier files into /Apps/AutoFileEmail/. That's the only destination, locked by the App folder scope.

When Pro ships (5 inboxes, custom destination folders, $14.99/mo), some users will want files going somewhere else - say, a shared OneDrive folder named Receipts/ that their bookkeeper has access to. That requires a broader scope (Files.ReadWrite instead of Files.ReadWrite.AppFolder).

Microsoft's incremental consent flow handles this cleanly. When you upgrade to Pro and pick a custom destination, AutoFileEmail re-prompts you for the broader scope. The old Files.ReadWrite.AppFolder permission stays active alongside the new one until the upgrade completes, then we migrate. You don't lose access to anything during the switch.

If your IT department needs to re-approve the broader scope, you'll see the "Approval required" screen again at upgrade time. Same one-line ask to IT. Same approval flow.

For now, free tier and /Apps/AutoFileEmail/ is the working pair. Pro and custom destinations are on the waitlist.

Why we're not just shipping a Power Automate template

Reasonable question. Microsoft's Power Automate already does ~80% of this for free with M365.

Five reasons we built our own anyway:

Domain routing is the 80/20. A flat dump of attachments isn't useful at tax time. Your accountant doesn't want one folder with 600 PDFs; they want them split by vendor. Power Automate can do this with custom expressions, but most users won't write them, and the ones who do find the expressions break in edge cases when sender headers are malformed.

Power Automate has action limits. 750 actions/day on the free tier. A user with 30 vendors emailing receipts averages 100+ actions a day during busy seasons. Premium licensing starts at $15/user/month - more than our Pro tier.

No retroactive backfill. Power Automate triggers on new mail going forward. There's no native "process my last 3 years of inbox" path. We built backfill specifically because nobody else does it well. The $29 Tax Year Pack covers a full year retroactively. No per-email surcharge.

Tax-relevant deduplication. Our (account_id, message_id, filename) unique index means no duplicates regardless of how many times we re-process a message. Power Automate flows can double-file in edge cases.

One product, two clouds. Same dashboard, same folder structure, same logic, regardless of whether your inbox is Gmail or Outlook and whether your storage is Drive or OneDrive. Power Automate locks you to Microsoft.

If your needs are very simple (one vendor, one folder, fewer than 750 attachments a day), Power Automate is genuinely fine. It's free with M365. If your needs are anything beyond that, the math shifts hard toward purpose-built.

The freelancer-on-Outlook playbook

If you're a freelancer or solo founder on Outlook, the working setup is:

Sign up at autofile.email with your Microsoft account. 30 seconds.
Connect Outlook + OneDrive in onboarding. Two minutes.
Let the 30-day backfill catch up. Within a few minutes you'll see April's receipts already in OneDrive.
If you want the last full tax year filed too, buy the $29 Tax Year Pack. One-time payment, no subscription. Backfill runs in the background.
Every receipt going forward files itself within 30 seconds of arriving.

For a deeper look at why the auto-filing approach beats the OCR-everything alternative, see why we don't OCR your receipts.

TL;DR

AutoFileEmail's Outlook + OneDrive integration is live. Two OAuth screens, no Power Automate, no custom expressions.
Files land under /Apps/AutoFileEmail/{vendor-domain}/{YYYY}/{MM}/ in OneDrive. App folder mode means we cannot see anything else in your OneDrive.
Microsoft scopes: Mail.Read for Outlook, Files.ReadWrite.AppFolder + User.Read for OneDrive. That's the entire footprint.
M365 work accounts may need IT to grant tenant or per-user consent. The ask is small because the scope is small.
Pro (custom destination folders, 5 inboxes) is on the waitlist. Microsoft's incremental consent flow handles the upgrade cleanly when it ships.

Free for one inbox + one cloud, no credit card, no per-receipt fees. Connect Outlook and OneDrive today and your April receipts are filed before you finish your coffee.

We don't read your receipts. We just file them.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/outlook-onedrive-freelancer-filing-setup/outlook-one-drive-freelancer-filing-setup-banner-04d752df-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Dext Alternatives for One-Person Businesses]]></title>
            <link>https://autofile.email/blog/dext-alternatives-for-one-person-businesses</link>
            <guid isPermaLink="false">https://autofile.email/blog/dext-alternatives-for-one-person-businesses</guid>
            <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Most Dext alternatives are also OCR bookkeeping tools, priced like it. Here's the honest list, what each one is really for, and when you need none of them.]]></description>
            <content:encoded><![CDATA[Studio Ghibli style banner featuring a cozy, sunlit home office desk with stacks of neat paper folders and a vintage lamp. Soft pastel color palette of warm cream, gentle greens, and amber lighting. Dreamy atmosphere. Text overlay reads: "Dext Alternatives for One-Person Businesses" in bold white typography.

Someone told you Dext was the answer. Then you opened the pricing page.

$25.21 a month, excluding tax. Five users. 250 documents. You are one user. You get maybe forty receipts a month, and your "bookkeeping process" is a shoebox that happens to be a Gmail account.

So you searched for Dext alternatives, and every result was another OCR tool priced for an accounting firm.

Here is the thing nobody selling you these tools will say: the entire category exists to turn receipts into ledger entries. If nobody is making ledger entries from your receipts, you are shopping in the wrong aisle.

Table of Contents

What Dext actually does

The real alternatives, and what each is actually for

  AutoEntry
  Hubdoc
  Expensify
  Receiptor AI and the newer inbox scanners
  Zapier, Power Automate, Apps Script

The question that decides it

What "none of the above" looks like

Why the free tiers elsewhere are short

TL;DR

What Dext actually does

Dext reads your receipts. It pulls out the vendor, the total, the tax, and often the individual line items, and it pushes that structured data into Xero, QuickBooks or Sage as something a bookkeeper can reconcile against a bank feed.

That is the product. The receipt-collecting part, the email inbox, the mobile snap, the supplier statements, all of it feeds the extraction engine. Extraction is the thing you are paying for.

Current list price, read off dext.com on 23 September 2026: the Business plan is $25.21 per month excluding tax, or $302.50 billed annually. That covers 5 users and 250 documents per month. Plans for accounting practices are priced per client per month, with a minimum of ten clients.

That price is not unreasonable. For a practice posting a few thousand documents a month, it is cheap. The question is whether you are that.

Illustration of receipts being organized and extracted in a dreamy Studio Ghibli office

The real alternatives, and what each is actually for

AutoEntry

The closest like-for-like. Same job as Dext, credit-based pricing instead of document tiers: Bronze at $13 a month for 50 credits, Silver $24 for 100, Gold $46 for 200, and up through Platinum, Diamond and Sapphire. A purchase or sales invoice costs 1 credit, an invoice with line items costs 2, and a bank statement costs 3 credits per page. Unlimited users on every plan, and unused credits roll for 90 days.

Cheaper at the bottom end than Dext, and the credit model suits lumpy volume. Still an extraction tool. We wrote a longer piece on Dext vs AutoEntry if you are choosing between exactly those two.

Hubdoc

Bundled with Xero rather than sold on its own. If you already pay for Xero, you already have it, and it fetches statements and bills and pushes them through. If you do not use Xero, it is not really available to you as a standalone purchase. Worth knowing before you spend an afternoon evaluating it.

Expensify

A different animal wearing similar clothing. Expensify is built around expense reports, approvals and reimbursement, which is a workflow that only exists when one person spends money and another person signs off on it. If you are one person, there is nobody to approve anything.

Receiptor AI and the newer inbox scanners

A wave of tools that connect to your mailbox, find receipts with a model, extract the data, and hand you a CSV. Genuinely useful if you want a spreadsheet of your spending. Also means a third party is reading every invoice in your inbox, which is a trade some people make happily and others find out about later.

Zapier, Power Automate, Apps Script

The build-it-yourself tier. Real, free-ish, and it works until a vendor changes their sending address. We went through the actual failure modes in Zapier vs IFTTT vs purpose-built.

Freelancer looking at different software pricing plans on a laptop in a cozy room

The question that decides it

Not "which is cheapest". This one:

Is anyone turning your receipts into accounting entries?

If yes, a bookkeeper, an accountant who does monthly reconciliation, or you in Xero on the last Sunday of the month, then buy an extraction tool. Dext or AutoEntry, pick on price and volume, and stop reading.

If no, and for most one-person businesses the answer is no, then extraction is a feature you are paying for and throwing away. Your accountant gets the shoebox once a year and does the categorising themselves. We asked a few of them, and the answer was consistently "just give me folders".

Quiet workspace with organized folders and a cup of tea representing calm bookkeeping

What "none of the above" looks like

You still have a real problem. The receipts are scattered across four years of Gmail, half the vendors changed their sending address, and April is a three-hour archaeology session. That problem is worth solving. It just does not need OCR.

What it needs is filing: the attachment comes out of the email and lands somewhere with a structure, automatically, the day it arrives. Sender domain, year, month. Nothing reads the file. Nothing extracts anything.

That is the whole of what AutoFileEmail does. A receipt from Stripe goes to /AutoFileEmail/stripe.com/2026/09/. One from AWS goes next door. When your accountant asks for 2026, you share one folder.

Because there is no OCR, there is no GPU bill, which is why one inbox is free forever rather than free for fourteen days. Pro is $14.99 a month or $149 a year when you need more inboxes. The back years are a one-time Backfill Pack, $29 to $99, not a subscription.

The side-by-side against Dext has the full table if you want it.

Neat filing system with folders categorized by year and month in a Ghibli style room

Why the free tiers elsewhere are short

Worth understanding, because it explains the whole market. OCR costs money per document, every document, forever. Any tool built on extraction has to meter you, and that is why the pricing is per document or per credit and why trials end. It is not greed, it is arithmetic. We wrote out the math.

A filing tool has no per-document cost worth billing for. Different economics, different pricing, and it only works because we gave up the feature everyone else sells.

Simple arithmetic and pricing concept illustrated in a whimsical cozy workspace

TL;DR

Dext Business is $25.21/mo excl. tax, 5 users, 250 documents. AutoEntry starts at $13/mo for 50 credits. Both are OCR tools and both are fine at that.
Hubdoc means Xero. Expensify means approvals and reimbursement. Neither fits a one-person business.
The deciding question is whether anyone reconciles your receipts into a ledger. If nobody does, you are paying for extraction you discard.
If you just need the PDFs findable in April, you need filing, not reading, and that costs nothing for one inbox.

Prices here were read from each vendor's own pricing page on 23 September 2026. Check them before you buy, pricing pages move.

Summary checklist for solo business owners choosing between OCR and simple filing
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/dext-alternatives-for-one-person-businesses/dext-alternatives-for-one-person-businesses-banner-b669aa61-1200.jpg" length="0" type="image/jpg"/>
        </item>
        <item>
            <title><![CDATA[Dext vs AutoEntry (And Whether You Need Either)]]></title>
            <link>https://autofile.email/blog/dext-vs-autoentry-for-solo-operators</link>
            <guid isPermaLink="false">https://autofile.email/blog/dext-vs-autoentry-for-solo-operators</guid>
            <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Dext bills per document, AutoEntry bills per credit. Here's the real pricing side by side, and the question that decides whether you need an OCR tool at all.]]></description>
            <content:encoded><![CDATA[Studio Ghibli style banner featuring a cozy, magical accounting desk with stacks of neatly organized paper invoices, a vintage calculator, and a warm green desk lamp. Soft pastel tones, dreamy lighting, warm inviting atmosphere. Text overlay: "Dext vs AutoEntry (And Whether You Need Either)" in bold clean white typography on a light-colored rounded card.

These two get compared constantly, and the comparison is usually written by someone who sells one of them.

Both read receipts. Both push the extracted data into Xero, QuickBooks or Sage. The differences are real but narrow: how they meter you, and what happens when your volume is lumpy.

And then there is a third option that neither vendor will mention, which is that a lot of people searching this comparison do not need an extraction tool at all.

Table of Contents

The pricing, side by side
How to actually compare them
Users, and why it matters less than it looks
The question neither vendor asks
What you might need instead
If you do want extraction
TL;DR

The pricing, side by side

Read from each vendor's own pricing page on 23 September 2026.

Dext Business

$25.21 per month, excluding tax
$302.50 billed annually
Includes 5 users and 250 documents per month
Over that, you are into custom pricing

AutoEntry

Bronze: $13 per month, 50 credits
Silver: $24 per month, 100 credits
Gold: $46 per month, 200 credits
Platinum: $103 per month, 500 credits
Diamond: $298 per month, 1,500 credits
Sapphire: $469 per month, 2,500 credits
Unlimited users on every plan

The catch with credits is that a credit is not a document. A purchase or sales invoice costs 1 credit. An invoice where you want the line items costs 2. A bank statement costs 3 credits per page.

So a 10-page bank statement is 30 credits. Bronze is 50 credits. You can burn a month's allowance on one statement and a handful of invoices.

Studio Ghibli aesthetic. A friendly accountant sitting at a rustic wooden desk, carefully reviewing pricing charts and ledger documents by a window with soft pastel sunlight streaming through. Warm, cozy, and calm mood.

How to actually compare them

Convert both to documents-per-dollar for your document mix, not the vendor's.

If your documents are mostly plain invoices with no line-item extraction, AutoEntry Silver gives you 100 documents for $24. Dext gives you 250 for $25.21. Dext wins clearly.

If you send a lot of bank statement pages, AutoEntry's 3-credits-per-page adds up fast and Dext's flat document count looks better again.

If you are well under 50 documents a month and never touch bank statements, AutoEntry Bronze at $13 is the cheapest real option on the table.

AutoEntry's unused credits roll for 90 days, which genuinely helps if your volume spikes at quarter end. Dext's allowance does not roll.

Rough rule: under about 50 simple documents a month, AutoEntry Bronze is cheapest. Above that, Dext's 250-document allowance is usually better value. That is the whole comparison, and it is smaller than the amount of content written about it.

Studio Ghibli aesthetic. A freelancer at a tidy desk counting stacks of paper receipts and bank statements, surrounded by indoor green plants and gentle afternoon light.

Users, and why it matters less than it looks

AutoEntry gives unlimited users on every plan. Dext Business includes five. This reads like a big difference and mostly is not, because the buyer searching this comparison is usually one person, or one person plus an accountant who has their own login anyway.

If you are a practice, you are not on these plans at all: Dext prices practices per client per month with a ten-client minimum, and that is a different negotiation.

Studio Ghibli aesthetic. Two colleagues smiling and reviewing business documents together in a sunlit wooden office with warm pastel walls and comfortable seating.

The question neither vendor asks

Both of these tools exist to turn a PDF into a row in a ledger.

So: who is reading those rows?

If you have a bookkeeper, or you reconcile in Xero monthly, the rows get used and the subscription earns out. Pick on the volume math above and get on with your day.

If you are a freelancer or a one-person company whose entire accounting process is handing a folder to an accountant in March, the extraction happens and then nothing consumes it. You are paying $13 to $25 a month to generate data that dies in a dashboard.

We put this to a few indie-founder accountants and the response was consistent enough to write up: they do not want your categorised data, they want the PDFs in named folders. Hand-categorised data from a non-accountant often makes their job harder, because now they have to check it.

Studio Ghibli aesthetic. A solo entrepreneur handing a neatly organized folder of receipts to a friendly accountant across a warm wooden desk. Soft dreamy lighting and comforting atmosphere.

What you might need instead

The underlying problem is usually not "my receipts are not categorised". It is "my receipts are 4,000 emails deep in Gmail and I cannot find the AWS one from March 2024".

That is a filing problem. It is solved by taking the attachment out of the email and putting it somewhere structured the day it arrives, which needs no OCR, no credits and no document cap.

AutoFileEmail does exactly that and nothing else. Receipts file to /AutoFileEmail/{sender-domain}/{year}/{month}/ in your own Google Drive, Dropbox or OneDrive. A Stripe invoice lands under stripe.com, an AWS one under amazon.com. We never open the file.

One inbox is free forever, because with no OCR there is no per-document cost to recover. Pro is $14.99 a month or $149 a year. Years already sitting in your inbox are a one-time Backfill Pack, $29 to $99.

There is a full table against Dext, and a wider list of Dext alternatives if you are still shopping.

Studio Ghibli aesthetic. A laptop screen glowing softly on a wooden table, with digital folders magically organizing paper documents into neat cloud storage drawers. Warm, whimsical lighting.

If you do want extraction

Then buy one of them, genuinely. Some honest advice:

Count your last three months of documents before choosing a tier. Most people guess high.
Count bank statement pages separately if you are looking at AutoEntry. They are the credit killer.
Check whether your accountant already has a preference. Many practices are standardised on one and will onboard you for free.
Check whether you are already paying for Xero, because Hubdoc is bundled and you may own a third option already.

Studio Ghibli aesthetic. A person with a cup of tea checking off a list on a notepad by a window, with soft morning pastel light and a peaceful outdoor garden view.

TL;DR

Dext Business: $25.21/mo excl. tax, 5 users, 250 documents. AutoEntry: from $13/mo for 50 credits, unlimited users, credits roll 90 days.
Under ~50 simple documents a month, AutoEntry Bronze is cheaper. Above that, Dext's 250 documents usually wins.
Bank statements cost 3 AutoEntry credits per page and wreck the cheap tiers.
Both only pay off if somebody consumes the extracted data. If nobody does, you want filing, not reading.

Prices were read from dext.com and autoentry.com on 23 September 2026. Verify before buying.

Studio Ghibli aesthetic. A cozy home workspace overview with a warm desk lamp lighting up a clean notebook, a small cactus plant, and a laptop displaying a financial summary. Soft pastel color palette.
]]></content:encoded>
            <author>support@autofile.email (Mitchel Kelonye)</author>
            <enclosure url="https://assets.kelmsoft.com/autofileemail/articles/dext-vs-autoentry-for-solo-operators/dext-vs-autoentry-comparison-dbb43ee1-1200.jpg" length="0" type="image/jpg"/>
        </item>
    </channel>
</rss>