Your Compliance check
InvoiceGenie · invoicegenie.app · sample report
ScopeEU, UK, and US (California) consumer and data-protection rules, plus accessibility and email marketing
Who can come after you
The groups below can hold you to an obligation, and what each one would find if they looked today. This is your exposure by who is on the other side, not just by rule. Open a row to read the detail.
CriticalEU and UK data protection regulators, and the people (or groups like noyb) who complain to them
2 findings
Tracking cookies drop before anyone agrees
Why it matters: In the EU and UK, analytics and ad cookies are only allowed after a visitor opts in, but this app sets Google Analytics and the Meta Pixel the instant the page loads, with no banner and no way to say no, and the Pixel ships visitor activity to Facebook. One annoyed visitor can file a free complaint, and noyb runs automated scans that catch exactly this and then mail a complaint to a named founder, while the UK ICO has been writing directly to sites that do it. For a solo founder that means an official letter demanding you fix it and explain yourself, with no legal team to absorb the worry. An accept-only banner would not save you either, because regulators require reject to be as easy as accept, so a bolted-on OK-only banner is itself a documented complaint target.
How to fix: Add a consent banner that blocks Google Analytics, the Meta Pixel, and every non-essential tag until the visitor clicks accept, with a Reject all button shown just as prominently as Accept all and nothing pre-ticked. A consent tool like Cookiebot or Osano wired so tags fire only after opt-in is the standard fix. Until they say yes, load nothing that sets a cookie.
Authority:ePrivacy Directive 2002/58/EC Art. 5(3)
A copy-paste privacy policy that still names another company
Why it matters: GDPR says you must clearly tell people who collects their data, why, how long you keep it, who you share it with, and how to exercise their rights. This policy is a template that still names a different company, which is the first thing a regulator or complainant points to as proof you never wrote your own. Because there is also no list of the firms you share data with (Google, Meta, your email and payment tools), you cannot honestly answer a data request, which turns a quick complaint into a slow, expensive one for a founder handling it alone.
How to fix: Rewrite the policy for this product specifically: name yourself as the controller, list the data and why you collect it, the lawful basis, retention, and the third parties you share with, and publish a sub-processor list. This fixes the disclosure gap, it does not by itself make you compliant, since the underlying practices still have to match what you write.
Authority:GDPR (EU) 2016/679 Art. 13 and 14
ImportantA California resident, and the California Attorney General or Privacy Protection Agency
2 findings
Ad pixels fire on load with no Do Not Sell or Share link
Why it matters: When the Meta Pixel and Google Analytics load on page view, they pass a California visitor's identifiers and browsing to Meta and Google for ad targeting, which California law treats as selling or sharing, and any business doing it must post a clear Do Not Sell or Share My Personal Information link. This app has none. The California Attorney General and the Privacy Protection Agency run sweeps that start exactly here, by loading a site, watching the pixels fire, and checking for the link, then sending a notice. If you do not fix it inside the cure window it can become an enforcement action with civil penalties up to 2,500 dollars per violation, or 7,500 dollars if treated as intentional, counted per consumer.
How to fix: Add a clearly labeled Do Not Sell or Share My Personal Information link in the footer that actually stops the Meta Pixel and Google Analytics from loading for people who use it, and honor the Global Privacy Control browser signal so opt-outs apply automatically. The simplest path is a consent tool that blocks those tags by default for California traffic.
Authority:CCPA / CPRA Cal. Civ. Code 1798.120
No way for a Californian to see, delete, or opt out
Why it matters: California gives consumers the right to know, delete, correct, and opt out, and your privacy policy must spell out those rights and give at least one way to submit a request. Here the policy is a copied template that even names a different company, and there is no delete-my-account or request mechanism anywhere. If a Californian or an advocacy group sends a rights request and you cannot receive or honor it, that ignored request becomes the evidence in a complaint to the California Privacy Protection Agency, the primary enforcer, and we never had a process is what turns a warning into an enforcement file.
How to fix: Rewrite the policy with a real California rights section (know, delete, correct, opt out) and publish at least one working way to submit a request, such as a simple form or a monitored privacy email, then set a basic process to respond within the required window. Confirm a real person and inbox stand behind it, since an outside scan cannot see that.
Authority:CCPA / CPRA Cal. Civ. Code 1798.130
ImportantAn accessibility plaintiff sending an ADA demand letter
2 findings
Images have no alt text, the top thing demand-letter lawyers screen for
Why it matters: Law firms run automated scanners across thousands of small US sites looking for missing alt text, then mail a settlement demand to the owner. They target solo founders on purpose, because you are more likely to pay a few thousand dollars to make it go away than hire a lawyer. A blind person using a screen reader hears nothing where your images are, so the claim that the site is unusable is easy to make. This is a US demand-letter pattern, so it is about legal pressure on you rather than a guaranteed ruling, but the letter and the cost are real.
How to fix: Add a short, descriptive alt attribute to every meaningful image, for example alt="Invoice preview for Acme Co", and use alt="" for purely decorative images so screen readers skip them.
Authority:WCAG 2.2 SC 1.1.1 Non-text Content
Grey-on-white body text fails the contrast rule
Why it matters: Low-contrast text fails for anyone with aging eyes, low vision, or a phone in sunlight, and it is one of the easiest violations for an automated tool to detect and tally. It is the most common accessibility failure and one of the cheapest to fix, which is why it sits below the items that actually generate letters, but a long list of contrast failures still makes a small site look careless and pads out a demand letter.
How to fix: Darken body text to at least a 4.5:1 ratio against its background, for example #595959 or darker on white, and check large headings meet 3:1. The free WebAIM contrast checker confirms each color pair.
Authority:WCAG 2.2 SC 1.4.3 Contrast (Minimum)
ImportantYour own EU users exercising their data rights
2 findings
No way to see or delete data, and an ignored request becomes the complaint
Why it matters: Under GDPR anyone in the EU or UK can ask for a copy of their data or to delete it, and you generally have one month to respond. The trigger is not the missing button, it is ignoring the request. If a user emails you and gets silence, that single ignored email is what they forward to a regulator, and I did not have a process is not a defense. For a solo founder this is the most common way a quiet account turns into an official complaint.
How to fix: Add a clear way to request access and deletion, even a monitored privacy email plus a self-serve delete-my-account button, and write down a simple process so you can actually respond within a month. Because an outside scan cannot see your internal handling, confirm there is a real person and inbox behind it.
Authority:GDPR (EU) 2016/679 Art. 15
AI writes invoice content with no disclosure to the customer
Why it matters: The app turns a sentence into amounts, terms, and client-facing wording with no human in the loop, and nowhere says the content is AI-generated. When that processing involves a person's data, GDPR's transparency rules expect you to tell people meaningful information about automated processing that affects them. If a client disputes an AI-mangled invoice or asks how it was produced, you have no disclosure to point to, and a data-rights complaint to an EU regulator is free for them to file and slow for you to answer. This is a likely gap, not a confirmed violation, because whether the stricter solely-automated-decision rules bite depends on details only you can see.
How to fix: Add a short, honest section to your privacy policy, and ideally near the invoice itself, explaining that invoices are generated automatically by an AI model and that a human can review or correct them on request. Make sure a person can actually intervene if a customer asks.
Authority:GDPR (EU) 2016/679 Art. 13 and 14
We ran 112 applicable checks across GDPR, ePrivacy/PECR, CCPA/CPRA, EU AI Act, Accessibility, Marketing.
Not applicable to this product
- –COPPA (children's privacy): InvoiceGenie is a business invoicing tool with no audience of children under 13 and no child-directed content, so the US children's privacy rules do not apply.
- –HIPAA (health data): The app handles invoicing and contact data, not protected health information, so US health-privacy rules do not apply.
Could not fully judge from outside
- !Data Processing Agreements and sub-processor contracts: We can see that no DPA or sub-processor list is published on the site, but we cannot see the contracts you may hold privately with Google, Meta, or your email and payment vendors, so the internal paperwork is out of view from an outside scan.
- !Internal data-rights handling (DSAR response process): An external scan can confirm there is no visible way to submit an access or deletion request, but it cannot see whether a real person and inbox stand behind a privacy address, so confirm that internally.
InvoiceGenie is a one-person app selling into the EU, UK, and California while doing several specific things that reliably draw complaints, demand letters, or fines, and none of them are visible from the screen you ship. Tracking and advertising cookies fire on the very first page load with no consent and no way to reject, there is no California "Do Not Sell or Share" link and no way for anyone to see or delete their data, and the privacy policy is a copied template that still names a different company. This is a representative sample on a demo app and an automated scan is a starting point, not legal advice, but the pattern here is the exact pattern that gets small founders a letter.
Independently verified (in tested scope)
Checks that ran and passed, each backed by a deterministic observation and scoped to the rule it tested, never a claim of full compliance.
- ✓The site is served over HTTPSVerified
HTTPS scheme served on the live origin
tested: Security
- ✓HSTS is on, so browsers refuse to drop back to plain HTTPVerified
Strict-Transport-Security response header present
tested: Security
- ✓A privacy policy is published and linkedVerified
privacy policy link found on the site
tested: GDPR / ePrivacy
This is an automated compliance scan and a starting point, not legal advice. For anything high-stakes, talk to a lawyer.
You are dropping EU and UK tracking cookies before anyone agrees, which is the single most common cookie complaint trigger
WhereEvery page of the marketing site and the signup app: Google Analytics and Meta Pixel scripts sit in the page head and fire on load. No consent banner appears anywhere.
Why it matters: In the EU and UK, analytics and advertising cookies are only allowed AFTER the visitor opts in. You are setting them the instant the page loads, with no banner and no way to say no, and the Meta Pixel ships visitor activity straight to Facebook. A single annoyed visitor or a privacy group like noyb can file a free complaint with a data protection authority, and noyb runs automated scans that catch exactly this and then mail a complaint to a named founder. In the UK the ICO has been writing directly to sites that do this. For a solo founder that means an official letter demanding you fix it and explain yourself, with no legal team to absorb the worry or the cost.
Evidence
On first load of invoicegenie.app, before any interaction, the page scripts write advertising and analytics cookies, for example _fbp=fb.1... (Meta Pixel) and _ga / _gid (Google Analytics), and requests fire to connect.facebook.net/en_US/fbevents.js, www.google-analytics.com/g/collect, and www.googletagmanager.com. No cookie banner or reject option appears anywhere in the rendered page, and no script gates these tags behind a choice.
How to fix: Add a consent banner that blocks Google Analytics, the Meta Pixel, and any non-essential tag from loading until the visitor clicks accept, with a reject option that is just as easy as accept. A consent management tool (for example Cookiebot, Osano, or a self-hosted setup) wired so tags only fire after opt-in is the standard fix. Until they say yes, load nothing that sets a cookie.
Rule:ePrivacy Directive Article 5(3) (consent before storing or accessing information on a user's device); UK PECR Regulation 6 (consent for cookies and similar technologies)
There is no way to reject cookies, so even if you add a banner later, an accept-only banner does not count as consent
WhereSite-wide. No consent UI exists at all, so there is no reject path. This also heads off the common wrong fix of an accept-only or 'by using this site you agree' banner.
Why it matters: Regulators have been clear that consent must be a real choice, which means reject has to be as easy as accept. A lot of founders panic, bolt on a banner with only an 'OK' button or an 'X', and think they are safe. They are not, and that style of banner is itself now a documented complaint target across the EU and UK. The person who can act on this is the same as for the cookies finding, a regulator or a complainant, and the specific danger here is that you spend money on a banner that still earns you a letter.
Evidence
No consent mechanism is present in the page at all, confirmed by the absence of any consent cookie (no CookieConsent, OptanonConsent, or similar) and no banner element in the DOM on load. Because tracking fires immediately, there is by definition no reject-first state for a visitor to choose.
How to fix: When you build the banner, give it a clear 'Reject all' button shown with the same prominence as 'Accept all', do not pre-tick any boxes, and make sure nothing non-essential loads in the default state before a choice is made.
Rule:EDPB Guidelines 03/2022 on deceptive design patterns (reject must be as easy as accept); GDPR Article 4(11) (definition of consent: freely given, specific, informed)
Your privacy policy is a copy-paste template that still names another company, and it is missing the disclosures the law requires
Where/privacy (privacy policy page): generic template wording, a leftover reference to a different company name, no named controller, no stated purposes or lawful basis, no retention period, no mention of EU-to-US transfers, and no Data Processing Agreement or sub-processor list anywhere on the site.
Why it matters: GDPR says you must clearly tell people who is collecting their data, why, how long you keep it, who you share it with, and how to exercise their rights. A template that names someone else is proof you never wrote your own, and it is the first thing a regulator or a complainant points to. Because you also have no list of the companies you share data with (Google, Meta, your email and payment tools), you cannot honestly answer a data request, which makes a quick complaint into a slow, expensive one.
Evidence
The /privacy page reads as a generic template and contains a stray sentence referencing a different company, e.g. '...services provided by [OtherCompany Inc.]...'. There is no named controller, no stated lawful basis under Article 6, no retention period, no 'international transfers' section, and no sub-processor list or DPA link anywhere on the site.
How to fix: Rewrite the policy for InvoiceGenie specifically: name yourself as the controller, list the data and why you collect it, the lawful basis, how long you keep it, and the third parties you share with. Publish a sub-processor list and make a DPA available for business customers. This fixes the disclosure gap; it does not by itself make you compliant, the underlying practices have to match what you write.
Rule:GDPR Articles 13 and 14 (information to be provided to data subjects)
The Meta Pixel and Google Analytics fire the moment your page loads, which California treats as 'selling' or 'sharing' personal info, and you have no 'Do Not Sell or Share' link
WhereEvery public page and the signup app (Meta Pixel and Google Analytics tags in the page head), plus the missing footer link.
Why it matters: When the Meta Pixel and Google Analytics load, they pass a California visitor's identifiers and browsing to Meta and Google for ad targeting. Under California law that counts as 'selling' or 'sharing,' and any business that does it has to post a clear 'Do Not Sell or Share My Personal Information' link so people can opt out. You have none. The California Attorney General and the California Privacy Protection Agency run sweeps that start exactly here, by loading a site, watching the ad pixels fire, and checking for the link. They send a notice, and if you do not fix it inside the cure window it can turn into an enforcement action with civil penalties up to 2,500 dollars per violation, or 7,500 dollars if they decide it was intentional, counted per consumer.
Evidence
On page load, before any interaction, the browser fires requests to connect.facebook.net (fbevents.js) and www.googletagmanager.com / google-analytics.com, and Meta's _fbp and Google's _ga cookies are written. A full scan of the footer and privacy page finds no link or button with text matching 'Do Not Sell' or 'Do Not Share,' and no opt-out control of any kind is present.
How to fix: Add a clearly labeled 'Do Not Sell or Share My Personal Information' link in your footer that actually stops the Meta Pixel and Google Analytics from loading for people who use it, and honor the Global Privacy Control browser signal so opt-outs apply automatically. The simplest path is a consent tool that blocks those tags by default for California traffic.
Rule:CCPA/CPRA right to opt out of sale or sharing (Cal. Civ. Code 1798.120); CCPA/CPRA required 'Do Not Sell or Share My Personal Information' link (Cal. Civ. Code 1798.135)
Your chat widget and US trackers send EU visitor data abroad on page load, with nothing in your policy that says so
WhereIntercom-style chat widget plus Google Analytics and Meta Pixel, all loading before consent on every page. The privacy policy has no cookie or tracker disclosure.
Why it matters: These tools quietly load on the first visit and start collecting an EU visitor's IP address and browsing behavior, then ship it to US companies, all before the person is told or asked. On top of the consent problem, your policy says nothing about which cookies you set, who runs them, or that data leaves the EU. When a complaint comes in, the first thing a regulator asks for is your cookie list and your notice, and having neither turns a quick complaint into a drawn-out one that is harder and more expensive to close.
Evidence
On initial load, third-party requests fire to Intercom (widget.intercom.io or similar), www.google-analytics.com, and connect.facebook.net, each setting or reading device identifiers before any interaction. The privacy policy contains no cookie table, no named third parties, and no mention of cross-border data flows, and it names a different company in one section, which is a verifiable tell that it is a copied template rather than written for this app.
How to fix: List every cookie and tracker you set and who runs it in a cookie notice, load the chat widget and trackers only after consent where they are not strictly necessary, and write a cookie section in the policy that names these providers honestly.
Rule:ePrivacy Directive Article 5(3) (notice and consent for cookies set); GDPR Article 13 (recipients and transfer information at collection); GDPR Article 44 (general principle for transfers of personal data out of the EU)
There is no way for a user to see or delete their data, and an ignored request is what turns a quiet account into an official complaint
WhereAccount/settings area and privacy policy: no 'delete my account', no data-export or access flow, no privacy contact or DSAR route visible anywhere.
Why it matters: Under GDPR anyone in the EU or UK can ask you for a copy of their data or to delete it, and you generally have one month to respond. The fine trigger is not the missing button, it is ignoring the request. If a user emails you and gets silence, that single ignored email is what they forward to a regulator, and 'I did not have a process' is not a defense. For a solo founder this is the most common way a quiet account turns into a complaint.
Evidence
The signup flow collects name, email, company, and payment, but the logged-in app shows no 'delete my account' control and no data-export or access option. The privacy policy lists no contact address or form for an access or deletion request. From the outside there is no visible DSAR path at all.
How to fix: Add a clear way to request access and deletion, even a monitored privacy@ email plus a self-serve 'delete my account' button, and write down a simple process so you can actually respond within a month. Because an outside scan cannot see your internal handling, confirm there is a real person and inbox behind it.
Rule:GDPR Article 15 (right of access); GDPR Article 17 (right to erasure)
A Californian has no way to ask you to delete, see, or stop selling their data, and your policy does not list those rights, so you could not answer a request even if one arrived
WherePrivacy policy (missing consumer-rights section) and the whole app (no data-rights request method).
Why it matters: California gives consumers the right to know what you have, delete it, correct it, and opt out, and the law requires your privacy policy to spell out those rights and give people at least one way to submit a request. Your policy is a copied template that even names a different company, and there is no 'delete my account' or request mechanism anywhere. The danger is timing: if a Californian or an advocacy group sends a rights request and you have no way to receive or honor it, that ignored request becomes the evidence in a complaint to the California Privacy Protection Agency, which is the primary enforcer, and 'we never had a process' is what turns a warning into an enforcement file.
Evidence
The privacy policy contains generic template text and references a company name unrelated to InvoiceGenie, and a search for a consumer-rights section (right to know / delete / correct / opt out) and a request method (form, email, or toll-free contact) returns nothing. The app has no 'delete my account' control and no request intake.
How to fix: Rewrite the privacy policy with a real California rights section (know, delete, correct, opt out) and publish at least one working way to submit a request, such as a simple form or a monitored privacy email, then set yourself a basic process to respond within the required window. Confirm a real person and inbox stand behind it, since an outside scan cannot see that.
Rule:CCPA/CPRA privacy policy disclosure of consumer rights and request methods (Cal. Civ. Code 1798.130); CCPA/CPRA opt-out mechanism (Cal. Civ. Code 1798.135)
Your images have no alt text, which is the single most common thing ADA demand-letter lawyers screen for
WhereMarketing site and signup app, multiple <img> elements (logo, hero image, feature screenshots).
Why it matters: Law firms run automated scanners across thousands of small US sites looking for missing alt text, then mail a settlement demand to the owner. They target solo founders on purpose because you are more likely to pay a few thousand dollars to make it go away than hire a lawyer. A blind person using a screen reader hears nothing where your images are, so the claim that your site is unusable is easy to make. This is a US demand-letter pattern, so it is about legal pressure on you rather than a guaranteed ruling.
Evidence
Page source shows images shipping with no text alternative, for example <img src="/hero.png"> and <img src="/feature-1.png" class="shadow">. No alt attribute is present on these elements, so a screen reader announces only the file name or nothing at all.
How to fix: Add a short, descriptive alt attribute to every meaningful image (alt="Invoice preview for Acme Co"), and use alt="" for purely decorative images so screen readers skip them.
You send marketing email, and an external scan finds no sign of an unsubscribe path or a real sender address, which is what gets you reported
WhereProduct and marketing emails sent from the app (signup confirmation plus marketing sends). Cannot verify message contents from outside, flagged for an internal check.
Why it matters: If you send marketing email to people in the US, the CAN-SPAM Act requires a working unsubscribe link, a real physical postal address, and honest subject lines, and similar rules apply for marketing consent in the EU and UK. The danger for a solo founder is not usually a fine on day one, it is that one annoyed recipient reports you, your sending domain gets a spam reputation hit, and your invoices and password resets start landing in junk folders. Losing deliverability quietly breaks the core product.
Evidence
The site states that product and marketing emails are sent, and the signup collects an email with no separate, unbundled opt-in for marketing versus transactional mail. An outside scan cannot open your sent messages, so it cannot confirm whether each marketing email carries a one-click unsubscribe link and a postal address. This is flagged as a likely gap to verify, not a confirmed violation.
How to fix: Make sure every marketing email has a clear one-click unsubscribe link and a real postal address, keep marketing opt-in separate from the transactional emails people need, and honor unsubscribes promptly. If you use an email provider like Postmark, Resend, or Mailchimp, these are usually built in but must be turned on and filled out.
Rule:CAN-SPAM Act commercial email requirements (unsubscribe, postal address, honest headers); GDPR Article 6 and ePrivacy rules on consent for marketing communications
Your grey-on-white body text is too faint to pass the contrast rule
WhereMarketing site and app body copy: light grey text on a white background.
Why it matters: Low-contrast text fails for anyone with aging eyes, low vision, or a phone in sunlight, and it is one of the easiest violations for an automated tool to detect and tally. It is the most common accessibility failure and one of the cheapest to fix, which is why it lands at lower priority than the items that actually generate letters, but a long list of contrast failures still makes a small site look careless.
Evidence
Body text appears to use a light grey such as #999999 on a #FFFFFF background. That is roughly a 2.85:1 contrast ratio, below the 4.5:1 minimum required for normal-size text. A contrast checker flags these as failures across most pages.
How to fix: Darken your body text to at least a 4.5:1 ratio against its background (for example #595959 or darker on white), and check large headings meet 3:1. Free tools like the WebAIM contrast checker confirm each color pair.
An AI writes your invoice content and you never disclose it, which weakens you if a customer disputes a charge
WhereInvoice generation flow and the privacy policy (no section on AI or automated processing).
Why it matters: Your app turns a sentence into amounts, terms, and client-facing wording with no human in the loop, and nowhere does it disclose that the content is AI-generated. When that processing involves a person's data, GDPR's transparency rules expect you to tell people meaningful information about automated processing that affects them, and emerging AI transparency norms point the same way. If a client disputes an AI-mangled invoice or asks how it was produced, you have no disclosure to point to, and a data-rights complaint to an EU regulator is free for them to file and slow for you to answer. This is a likely gap, not a confirmed violation, because whether the stricter 'solely automated decision' rules bite depends on details only you can see.
Evidence
The signup collects name, email, company, and payment, and the invoice is produced automatically from a prompt with no visible review step. The privacy policy is a generic template that names a different company in one place and contains no section on automated processing, profiling, or how AI-generated outputs are produced.
How to fix: Add a short, honest section to your privacy policy and ideally near the invoice itself explaining that invoices are generated automatically by an AI model and that a human can review or correct them on request. Make sure a person can actually intervene if a customer asks.
Rule:GDPR Articles 13 and 14 (transparency about automated processing); GDPR Article 22 (automated decision-making, may apply depending on the facts)
Your chat widget may be an AI bot that does not tell people they are talking to a machine
WhereThe Intercom-style chat widget that loads on the marketing site and app.
Why it matters: The EU AI Act says that when someone interacts with an AI system like a chatbot, they have to be told they are dealing with a machine unless it is obvious. If your widget answers with AI and presents itself like a person, an EU user who later feels misled can complain to a national authority. This is lower stakes than the invoice labelling and the transparency duty begins applying in August 2026, so it is more a fix-before-it-bites item than an active violation, but it is the kind of thing a privacy-minded user screenshots and reports.
Evidence
The chat widget fires on page load, styled as a person-to-person support chat with no opening line, badge, or persistent label stating that responses are automated or AI-generated. From the outside we cannot confirm whether a human or a bot answers, so this is flagged for an internal check.
How to fix: If the widget is AI-backed or auto-replies, add a clear up-front line such as 'You're chatting with an automated assistant.' If a human always answers, document that so this duty does not apply.
Rule:EU AI Act Article 50 (transparency: informing people they are interacting with an AI system)
This is what we would hand you
InvoiceGenie looks fine to its founder. None of this shows up on the screen, but it is exactly what a regulator, a California resident, or an accessibility plaintiff would look for. We scan your SaaS the way they would and hand you a private fix list, with the actual rule each issue touches, written so your AI coding tool can do the fixing.
Private to you, never published. Within 15 minutes. $15 one-time.