1. Define the service your firm will offer
List the client types, services, jurisdictions and tax workflows you need to support. Decide what clients will enter themselves, what your team will prepare, what a reviewer will check and which actions need client approval. Agree the branding, onboarding, support responsibilities and commercial model before designing screens.
Describe “nested” software in practical terms: an accounting-firm service with separately controlled client workspaces and appropriate practice oversight. Do not assume that a shared customer list provides this separation. Include migration, integrations, training, ongoing maintenance and regulatory change handling in the quotation discussion.
2. Design and verify each client boundary
Map the firm administrator, accountant, bookkeeper, reviewer and client roles. Specify who may see each workspace, record and document, and which sensitive actions require additional review. Client portal access and staff permissions must be tested against the actual deployment.
The existing MTD SaaS deployment guidance and tenant-isolation guide explain the intended boundaries. Acceptance testing must demonstrate that users cannot reach another client’s records or reuse that client’s HMRC authority. Verify restricted roles, revoked access and incorrect-workspace scenarios before onboarding live clients.
3. Establish the accounting source and digital trail
Define how invoices, expenses, banking activity and other agreed source records become reviewed accounting entries. Confirm who corrects errors, reconciles balances and approves the financial period. Accounting remains the authoritative ledger; a tax-submission layer must not become a second set of books.
For HMRC workflows, the configured accounting adapter must supply the required figures with transaction-level digital lineage. Use the Accounting-to-MTD preparation checklist to plan validation. Missing lineage is a blocker to resolve at source, not a reason to type replacement totals into a tax form to bypass the control.
5. Prove the supported HMRC journey before launch
Confirm the specific VAT or Income Tax workflows included in the proposal. Do not infer support for every tax return, payroll filing or statutory obligation from the phrase “HMRC integration”. Read the shared submission requirements guide alongside the agreed implementation scope.
Follow the production go-live checklist for digital links, endpoint testing, required API access, fraud-prevention context, authority, declarations and controlled acceptance. Income Tax final declaration is disabled by default until its production gate is satisfied. A successful sandbox example is not a completed production launch.
6. Use a tailored demo and an accountable operating plan
The standard demonstration covers CRM, practice management and accounting modules. Your firm needs a customised demonstration for its client platform: show two distinct client workspaces, restricted roles, source-to-ledger-to-tax preparation, approvals, filing responses and an exception. Use representative data and agree the acceptance evidence before implementation.
Define who reviews submission status, retains receipts and investigates uncertain outcomes. A network failure does not establish that HMRC rejected a submission; follow the unknown-outcome guidance before retrying. Agree support ownership and controlled change procedures. Contact Pixie for a customised demonstration and quotation, or return to the three accounting and practice management options.
