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.

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.

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.

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.

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.

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:

1. Receive receipts. Some include customer data.
2. They file into /AutoFileEmail/{vendor}/{YYYY}/{MM}/ in your own Drive.
3. Once a year, share the year's folder with your accountant. (Your accountant has their own DPA with you. Or should.)
4. Retain for 6-10 years per your country's tax law.
5. Customer asks for erasure: respond, identify what you legally must keep vs what you can delete, document your reasoning, send the response.
6. 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:

1. Knowing where customer personal data lives (in receipts, sometimes).
2. Having a lawful basis for keeping it (usually: legal obligation for tax records).
3. 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