Qwikr.tax

A business problem
worth solving.

An accounting practice manages different clients, reporting periods, source documents and financial processes at once. A useful platform has to preserve the boundaries between clients while making the day-to-day work understandable. Qwikr.tax addresses that breadth with a multi-tenant accounting platform for UK practices.

The connected solution.

A platform spanning invoicing, purchasing, bank reconciliation, financial reporting, expenses, fixed assets and client document workflows. The implementation also includes tax and payroll modules and integration surfaces for external providers.

The decisions behind
the experience.

Practice tenancy forms the foundation, with client and financial workflows built on top. Bank imports and rules support reconciliation, while invoices, bills and reports share the financial model. Practice branding, domains and client portal access allow the same platform to support distinct practice experiences. Sensitive integration tokens are handled through a separate encryption vault.

Separate the practice, the client and the financial record.

A practice platform has several distinct users and responsibilities. The underlying model needs to distinguish the practice workspace from the clients it serves and the transactions that belong to those clients. The feature structure spans document handling, invoicing, banking, accounting records, reports and client-facing interactions. That breadth is why a clear record model matters before screen-level polish.

The client portal and practice interface solve different jobs. A client needs to share information and act on documents; a practice needs to manage and review the financial workflow. Practice branding and domain configuration extend that distinction without requiring a separate product for each practice.

Reporting starts with the right records.

The ledger VAT totals service selects records for a defined period and excludes inappropriate document states and deleted records. It groups values from invoice lines or document headers, converts eligible amounts into the reporting currency and rounds the aggregated results. Records that cannot be converted are noted rather than silently treated as usable values.

The important engineering principle is traceability: a financial figure is the result of a selection rule, a currency treatment and an aggregation method. Those decisions belong in a shared calculation layer so a screen does not invent its own interpretation.

Test the journey as well as the formula.

Financial software has to connect computations to persisted documents and reports. The project’s engineering documentation contains audits that examine workflows, provider integrations, output generation and the relationship between calculated values and the ledger. Those reviews distinguish a feature’s presence from verified end-to-end behaviour.

For a platform like this, the useful validation questions are specific: which records contributed to the result, what happens to excluded data, whether the same document keeps its identity on retry, and whether tenant boundaries hold. Those are the kinds of constraints a bespoke financial workflow needs to make explicit.

Where the detail matters.

The experience behind the interface.

Binary Beach, part of TGF Digital, explores this build through its user journeys and product-design decisions.

Capability you can
put to work.

Demonstrates multi-tenant platform architecture, detailed financial workflows, secure integrations, reporting and white-label experiences.