A Login for Your Accountant, Not Your Sites

This is a blog post about a mySites.guru feature. Accountants can now log in to mySites.guru themselves to grab your past invoices.

If you run a web agency on mySites.guru, your accountant does not need to see your client sites. They need your invoices. And yet most SaaS tools force you to pick between two bad options: hand over full access and trust the bookkeeper not to poke around, or export a PDF of every invoice at month end and email the lot.

We built a third option. It is called the Accountant Portal and it is live today on every paid plan.

What Does the Accountant Portal Do?

The Accountant Portal is an account type that sits alongside team members. When you invite a user and choose the Accountant account type, that user can log in, see your invoices, open any invoice in detail, and email a copy to themselves. That is the complete list. Every other page in the app sends them back to the invoices.

That screenshot is the whole frame an accountant works in: the account the portal belongs to, who is signed in, and a Log out button. No sidebar, no tools menu, no team management, no settings. Invoices appear in the list on that page after each successful payment on the account.

Why Is the Accountant a Separate Role and Not a Permission Setting?

Team members now have per-site and per-feature permissions: you pick which sites each member sees, then set 14 areas such as Backups, Extension updates and Admin sign-in to None, View or Manage. So why not make “invoices only” one more setting in that matrix?

Because the matrix is built for people who work on sites, and an accountant never should. A custom team member always has at least View on Sites, since a member who cannot see their sites cannot do anything else either. Invoices, billing and subscriptions are not in the matrix at all: they stay with the account owner. An accountant needs the opposite shape, no sites and one thing from billing, so bolting them onto the matrix would mean special cases in both directions.

There is also the old worry about permission systems: every new feature (a new tool, a new audit, a new dashboard widget) is a page somebody has to remember to restrict. The team permissions deal with that by failing closed. Every route is put in an area or marked exempt, and a route that has not been classified yet is blocked for team members rather than allowed, with a test that names it. That is the right design for a colleague who needs most of the app.

For an accountant, who needs almost none of it, an even shorter list is simpler. Instead of classifying every route in the app, the Accountant Portal allows a handful of paths:

• /invoices (the list)
• /invoices/{id} (a single invoice, with its Email invoice to myself and Print buttons)
• sign in, sign out, password reset and two-factor pages

A request listener runs on every request, straight after the firewall and before any controller runs. If the signed-in user has ROLE_ACCOUNTANT and the path is not on that list, they are redirected to the invoices page. No controller has to opt in, and a feature added next year is out of reach on day one without anyone touching the accountant code.

How Do You Invite an Accountant?

Open your Team Members page and click Invite team member. Enter their name and email, then open the Account type pane and choose Accountant.

The help text under the option tells you what you are agreeing to: Views and emails invoices only. Sees no sites and nothing else, for your bookkeeper.

Choosing Accountant hides the Site access and Permissions panes, so no site is ever assigned and there is no way to add a “just this one site” exception. An account is a team member or an accountant, never both. The account saves, an invite email goes out with a password-reset link, and your accountant is up and running in under a minute.

What About Notifications and Activity Emails?

mySites.guru sends plenty of operational email: failed backups, security alerts, plugin update warnings, uptime pings. Your accountant does not want any of that, and you do not want them seeing it.

The getTeamMembers() call that feeds team notifications excludes accountants by default, and the site alert senders skip the accountant role as well. When your accountant wants a copy of an invoice in their inbox, they send it to themselves from the portal. You do not need to touch any notification preferences for this to work.

Can the Accountant Be Impersonated or Tricked Into Full Access?

No. The details that come up in security reviews:

• ROLE_ACCOUNTANT is written to the same roles column as every other role. One hasRole() check, enforced centrally, not scattered across controllers.
• The authenticator checks for ROLE_ACCOUNTANT on every successful sign-in and redirects to /invoices, ignoring any stored target path. Even a bookmarked deep link ends up on the captive page.
• An account owner can sign in as their accountant to check what they see, and the lockdown applies to the owner too while impersonating. The reverse is impossible: an accountant has no team page and no way to switch users.
• The lockdown listener runs on every request, not just HTML pages. AJAX and JSON endpoints are redirected to the invoices page too.
• Passkeys and 2FA work on accountant accounts the same as any other. I would recommend turning a passkey on regardless.

Why Does This Matter?

Bookkeepers are busy people handling invoices for a pile of clients at once. The last thing you want is yours clicking around in an unfamiliar control panel and accidentally triggering a backup restore or firing off an email to a client who has no idea who they are. “I’ll just have a quick look round” is how incidents start. With the Accountant Portal there is no “round” to look at, so the temptation never shows up.

It is also honest. When you give your accountant a login, they should know exactly what they can and cannot see. An account type whose own description says it sees no sites and nothing else leaves nothing to interpret. No one is “pretty sure” they cannot see client data. They demonstrably cannot.

Why Do We Not Auto-Email Financial Data?

Plenty of SaaS tools will happily pump your invoice data to whoever you point them at, on whatever schedule you pick. We will not.

Invoices are financial records. In the UK they fall under the UK GDPR and the Data Protection Act 2018, and the ICO’s own guidance is that plain SMTP email is not a secure channel for personal financial information. GDPR Article 32 (security of processing) says the same thing in EU terms. If your invoice touches anything health-related in the US, you are suddenly in HIPAA territory. Australia has the Privacy Act 1988. And the accounting regulators (ICAEW and AAT) expect members to keep client financial data inside access-controlled systems, not bouncing around inboxes.

Email is plaintext. It travels over servers you do not control, sits in spam filters you do not administer, and hangs around in archives long after the recipient has left the firm. Auto-emailing an invoice to an accountant every month means a year of invoices sitting across four or five mail hops, indefinitely. If their mailbox is compromised next year, so is your billing history.

The Accountant Portal inverts that flow. The accountant logs in with a password or a passkey, over TLS, to a page only they can see, and pulls the data when they need it. If they want a copy in their inbox, they can email a single invoice to themselves with one click. Same convenience, far less attack surface, and no one is wondering two years from now whether a closed Yahoo account still has a client’s billing address sat in it.

Why No PDFs?

The Accountant Portal does not render invoice PDFs. Invoices display as HTML, and if the accountant needs a saved file, their browser’s Print to PDF handles it. That is an intended choice, and we are in reasonably good company on it.

The Government Digital Service blog laid out why GOV.UK publishes content as HTML rather than PDF: PDFs are harder to search, awkward with screen readers, awkward to re-flow on mobile, and ignore the browser settings (text size, contrast, preferred font) that a lot of readers actually rely on. The government’s Accessibility team went further in 2023 and started stripping legacy PDFs off GOV.UK. The ONS has now stopped generating PDFs of its HTML content from 2026 onwards.

Not everyone got the memo. The States Assembly in Jersey has just moved the other way, making the PDF the authoritative version of each proposition and treating the HTML on the page as a convenience copy. Every publication now has an info box saying the PDF is the official document. Two governments, same decade, opposite conclusions. I would not bet on Jersey ageing well on that one.

Those reasons apply to invoices too:

• An HTML invoice respects the accountant’s screen reader, their zoom level, and their high-contrast setting. A PDF locks you into 10 point text at whatever font happened to be embedded, whether that works for them or not.
• If we change a VAT number, a trading address, or a line-item format, we edit one template and every historical invoice picks it up. Regenerating a decade of PDFs every time HMRC tweaks a required field is not a good use of anyone’s weekend.
• A rendered PDF of a simple invoice is routinely five to twenty times the size of the equivalent HTML. Across thousands of customers that becomes a lot of bandwidth and storage for a worse experience.
• Browsers already print HTML to PDF properly. The output is an accessible, tagged PDF that matches the reader’s display preferences. Two clicks in Chrome and your accountant has a filing copy that actually works with their tooling.

The part a lot of developers forget: every major operating system already has a first-class PDF renderer built in. macOS has had Print to PDF in the system print dialog since 2001. Windows 10 shipped Microsoft Print to PDF as a default printer back in 2015. Every mainstream Linux desktop exposes the same option via CUPS. Chrome, Safari, Firefox, and Edge all route into those system printers. So the PDF your accountant saves is one produced by Apple, Microsoft, or the CUPS team, using the same font rasterisation and colour management their operating system uses for everything else on screen.

Rendering a PDF server-side in PHP cannot get near that. The PHP options (mPDF, TCPDF, dompdf, wkhtmltopdf wrappers) are all fighting a frozen CSS subset, an embedded font list that never quite matches the source page, and assorted quirks around page breaks, ligatures, RTL text, emoji, and custom web fonts. I have lost enough Saturdays to TCPDF trying to line an invoice up with its HTML version to know the answer: ship the HTML, let the OS render the PDF.

One more reason, and it is one the PDF-by-default crowd rarely thinks about: printing is not eco-friendly. A PDF exists to look like a sheet of paper, and the natural next step with a PDF is to print it. A 2019 study by The Shift Project put the global digital industry at roughly 4% of greenhouse gas emissions, and paper is still the single biggest source of office waste in the UK according to Defra’s waste prevention programme. Every unneeded invoice PDF is an invitation to hit print, and every printed invoice is ink, toner, paper, electricity, and a delivery lorry somewhere up the supply chain.

An HTML invoice defaults to never being printed. If you want a filing copy you still can, but the default behaviour is “read it on the screen and close the tab” rather than “print it and put it in a folder that no one opens.” Small thing per invoice. Not a small thing across thousands of accountants filing thousands of clients.

HTML first, print on demand. The invoice you see is the invoice you get, and the format of any saved copy is yours to pick.

Give It a Try

Open your Team Members page, click Invite team member, and choose Accountant. Your accountant has a login in two minutes. If you do not yet have a mySites.guru account, pricing starts at £5/month for one site or £19.99/month for unlimited sites, and every plan includes unlimited team members, team permissions and accountants.

Add Your Accountant Now

Team access patterns like this one are covered in our agency multi-site management guide.