Read-only scope — what I can and cannot see

When this article is for you

You're a tax advisor and want to know exactly what you can see and do (or not do) once a client has invited you. This article is the canonical scope reference — both for self-orientation and for client conversations where they ask "wait, can my advisor see X?"

For the broader cockpit context, see tax-advisor cockpit. For the GDPR / processor-relationship framing, see GDPR considerations for tax advisors. For the invite flow itself, see invite your tax advisor from the client perspective.

What you can see (full read access)

These data domains are fully visible to you. Same view as the client, with the advisor-role UI affordances overlaid:

• Invoices — all documents the client has uploaded, with full extracted fields (vendor, dates, net / VAT / gross, currency, line items, category), confidence scores per field, the original PDF / image, full edit history.
• Transactions — bank-statement imports + their match status against invoices (matched / unmatched / partial-match).
• Trading partners — the client's vendor + customer registry, with vendor master data (canonical name, address, VAT ID, IBAN).
• Bank-statement summaries — aggregated views (balance over time, MTD cashflow, per-counterparty totals).
• Audit history — every action by anyone on the client's account, with timestamps, user IDs, and IP attribution. Includes your own actions; you don't have a privileged view of your own activity (it's logged like everyone else's).
• VAT-aggregation view for any period — input VAT (Vorsteuer) + output VAT (Umsatzsteuer) broken out by rate.
• Most settings in read-only mode — company name, base currency, plan tier, time zone. Settings you can't see at all (billing details, team list, integrations) are simply hidden.
• Exports run by the client — they're visible in your view as historical exports, with the periods they covered.
• Notification activity — what flags fired, what notifications were sent (to which user), what was acknowledged.

What you can do (limited write)

These actions are available to you. Each writes to the audit log with actor: tax_advisor:<your name>:

• Flag invoices with comments → routed to the client for action. See using flag templates.
• Approve invoices → marks them reviewed; leaves the queue. See the review queue explained.
• Withdraw a flag before the client has seen it (or even after, with the cost of a small "advisor changed their mind" audit entry).
• Add private notes to invoices — visible to you + other connected advisors at the same client. Not visible to the client. Useful for "asked about this by phone, awaiting callback" or cross-checks between firm-mates.
• Generate bulk exports for download — single client or cross-client. See bulk export as a tax advisor.
• Snooze items in your review queue to a future date.
• Bulk-approve up to 50 items per batch from your queue.

What you cannot see

These data domains are explicitly hidden from your view, even though they exist in the client's account:

• Client's inbox. We surface the extracted invoice attachments from their connected Gmail/Outlook — we never surface the inbox itself. You don't see emails that weren't classified as invoices, you don't see emails attached to wrong people, you don't see the client's personal correspondence even when it goes through the same inbox.
• Client's billing details. Credit card on file, billing address, past Stripe invoices, payment methods, plan-change history — all hidden. The client's Settings → Billing page shows you a "Plan: Business" line and nothing else.
• Client's other companies. If the same user runs multiple companies (e.g. a freelancer + their side-project SMB), you only see the one(s) they explicitly invited you to. The other companies don't appear in your view, can't be searched, can't be referenced.
• Other team members' personal data. Their teammates' email addresses, names, last-login times, role assignments — invisible. You see "uploaded by team member" without identifying who unless the team member's name is in an invoice authorship field that the client explicitly chose to surface.
• OAuth tokens or integration credentials. Encrypted on our side; not exposed in any API. You can't even see WHICH external services are connected (just that some are).

What you cannot do (blocked at the API layer)

• Upload new documents on behalf of the client. The client owns the upload action.
• Edit any invoice field directly. Vendor, amount, VAT rate, date, line items — none editable. You flag for the client to fix; they edit; auto-reset returns the invoice to your queue.
• Change the client's plan or modify billing in any way.
• Invite or remove team members from the client's company.
• Delete anything. Invoices, transactions, exports — nothing is deletable from your side. The client can delete; you cannot.
• Create matching rules. That's a client-side operation (with role gating — Bookkeeper+ on the client's team). You guide them through the create-rule flow but the create itself happens on their side. See creating a custom matching rule.
• Disconnect a client's email integration or bank connection. Same reason — they own the integration grant.
• Change the client's notification preferences or their per-invoice review threshold. They own these settings.

How the boundary is enforced

The read-only scope is enforced at the database query layer, not as a UI restriction. Every API call from your account is checked against the role you have on the relevant company (tax_advisor for clients who invited you).

This means: even if you opened DevTools, crafted a POST request to /api/invoices/123/edit, and sent it bypassing the UI, the server checks your role on company-123 and rejects the call with HTTP 403 because tax_advisor has no write scope on invoice.field_value.

The same applies to listing endpoints — /api/companies/ returns only the companies you've been invited to, not all companies on TaxItEasy. There's no is_admin shortcut that gives advisors broader access.

The constraint is a hard guarantee. Not a "best-effort UI hint."

Why it's designed this way

• Clean audit trail. Every data change has an attributable user — the client themselves, not "you-on-their-behalf." Comes up in tax-authority audits ("Did the client really book this expense at €5,000?") and in firm liability scenarios ("Did the advisor change the number?"). The answer is always traceable.
• No accidental data loss. You can't delete a client's data even if you wanted to. The client sleeps easier; you don't carry the responsibility for irreversible actions on someone else's books.
• Compliance simplicity. The boundary makes the GDPR processor-vs-controller-vs-sub-processor question clean. Client = controller, TaxItEasy = processor (with a signed DPA), tax advisor = sub-processor with strictly read + flag scope. See GDPR considerations for tax advisors for the full legal framing.
• Trust signal for the client. When a client invites an advisor, they're sharing their financial data. Knowing the advisor literally can't delete, modify, or exfiltrate without explicit client consent makes the invitation lower-stakes. Higher invite rate → more advisor-client relationships → broader TaxItEasy adoption.

Implications for common situations

"I really need to fix a typo for the client"

Flag with the custom message template ("VAT amount: it should be €123.45, not €124.45"). The client fixes in 30 seconds. Preserves the audit trail. Don't try to find a workaround for direct-edit; there isn't one and it's intentional.

"I'm an internal accountant employed by the company — same restrictions?"

Different role. Ask the company Owner to add you as Bookkeeper via Settings → Team → Invite member rather than inviting you as a tax advisor. Bookkeeper has write scope on the company's books (uploads, edits, exports, matching-rules-create) because it's an inside-the-company role.

The distinction: external advisor = read+flag, internal team member = full write. Bookkeeper is the internal-write role; tax-advisor is the external-read-with-flag role.

"Client wants me to upload documents on their behalf — I do their bookkeeping end-to-end"

Two options:

1. Bookkeeper role, as above. Best for arrangements where you really are an in-the-business bookkeeper.
2. Forwarding pipeline: client forwards documents to you, you forward onward to their u-<hash>@in.taxiteasy.org address. The inbound-email-pipeline doesn't care WHO forwarded the email; it processes the attachment and credits the document to the client's account. Audit log shows "forwarded by " so attribution is clean.

The forwarding-pipeline path is the conventional "advisor handles the upload-side of the work" pattern that respects the read-only scope on the database side.

"The client wants to add me to multiple companies — different invitation per company?"

Yes, one invite per company. The client has to be the Owner of each company (or have the multi-company arrangement set up by support). Your cockpit then shows each company as a separate client row.

If the client has a multi-company arrangement and only invited you to one company, you only see that one. Asking the client to invite you to the others is one form they fill per company.

"I want to share my advisor view with a colleague at my firm"

The colleague needs their own invite from the client. There's no "share view across advisors" feature today. The reason: each advisor's actions need to attribute to them individually in the audit log; sharing one login conflates attribution.

The client invites both you and your colleague separately. Both appear in their Settings → Tax Advisor page. Both have independent cockpit views of the same data.

Edge cases

The audit log shows actions I didn't take. Check the IP address column. If it's a known location (your office), it might be a colleague mis-attributed (shouldn't happen — one login per tax-advisor) — write to support. If it's an unfamiliar IP, treat as suspected unauthorised access — change password, revoke sessions, write to [email protected].

Client claims they revoked me but I still see their data. Revoke is immediate, but cached UI state can lag a few seconds. Refresh the page. If you still see the client after a hard refresh, write to support with the timestamp and client ID — revoke should be instant at the DB query layer.

I want to know who else is invited to a client. Visible in Settings → Tax Advisor → Other connected advisors on the client's page. You see a list of other tax-advisor names + emails + their last-activity timestamp. You don't see what they specifically did (only the audit log shows that).

My role on a client's company has changed — what now? Roles don't change silently. If you were tax_advisor and now you're getting access denials on actions that previously worked, write to support — possible bug or possible role-update by the client that they should communicate to you.

Two clients of mine have the same vendor (e.g. both use Hetzner) — can I copy a matching rule from one to the other? Not a one-click action because matching rules are client-side (you guide, they create). The practical workaround: tell the client of the second account what rule worked for the first; they recreate it. The rules live in each client's account independently.

I want to make a global change across all my clients (e.g. update my flag-template wording). Flag templates are platform-defaults, not per-advisor. You can't customise them today — see using flag templates for the workaround (free-text custom message + your own notes file).

Related

• Tax-advisor cockpit — where the scope manifests in the UI
• GDPR considerations for tax advisors — the legal framing for the boundary
• Invite your tax advisor — the client-side flow that creates the access
• The review queue, explained — the main write-scope surface (flag + approve)