Why this exists

Under the Tax Agent Services Act 2009 (TASA) and the TPB Code of Professional Conduct, a registered BAS or tax agent cannot lodge a BAS on a client's behalf without:

1. A written engagement letter scoping the work
2. Client authorisation linking the agent in ATO Online Services for Agents
3. A signed declaration of accuracy from the client BEFORE each BAS lodgement, retained for 5 years (TASA s30-35)

Frank's BAS sign-off workflow captures (3). The engagement letter flow on each practice client captures (1) — see Engagement Letters. (2) is handled outside Frank in ATO Online Services.

Workflow

1. Practice prepares BAS in Frank

The BAS data lives on the bas_periods table — practitioners enter or auto-derive G1, 1A, 1B, W1, W2, 5A from the client's transactions.

2. Practice sends for client sign-off

From /practice/bas, click "Send for review" on a draft. Frank:

• Snapshots the declaration text on the client_signoffs event log so even if the template changes later, the audit shows what THIS client agreed to
• Stores the SHA256 hash of the declaration text on the sent event
• Sets the projection status to sent (surfaced as sent_for_review to the frontend)
• Emails the client with a one-click link to the review page

3. Client reviews

The client lands on /bas-review/[id] — a clean page showing:

• Period covered + practice name
• Every BAS field with its dollar value
• The declaration text (default: "I confirm that the figures shown for this BAS period are accurate to the best of my knowledge and that the supporting records have been provided to my agent. I authorise [practice_name] to lodge this Business Activity Statement with the ATO on my behalf.")
• Single tick-box: "I confirm I have read and agree to the declaration above"
• Approve & authorise lodgement OR Send back to [practice] with a reason

On approve:

• Backend records a signed event with timestamp, signer user_id, IP, user agent, request_id, idempotency key, and a fresh SHA256 hash of the declaration text the client rendered
• The hash is compared against the sent event's hash — mismatch returns HTTP 409 (declaration_text_changed) and the sign-off is refused. Catches tampering.
• Practice sees the row move to "Approved — ready to lodge"

On reject:

• A rejected event is recorded with the reason
• Practice sees it under "Rejected — needs amendment" and can amend and resend (a new sent event closes out the rejection)

4. Practice lodges externally

Frank does NOT lodge to the ATO directly. The practitioner submits via ATO Online Services for Agents in the usual way, then comes back to Frank and clicks Mark lodged, optionally entering the ATO receipt reference. The lodgement is recorded on bas_drafts.lodged_at (BAS lifecycle) — separate from the signoff state, which stays signed.

Audit defensibility

What survives an audit:

• Append-only event log in client_signoff_events — every state transition (created, sent, signed, rejected) is one INSERT. The database trigger raises insufficient_privilege on any UPDATE or DELETE attempt, even from service_role.
• Tamper detection via SHA256 of declaration_text. The hash on the sent event is what the practice prepared. The hash on the signed event is what the client rendered. Mismatch = audit alert.
• Idempotency keys on every state-mutating POST. Prevents double-signing from network retries or scanner pre-clicks.
• Forensic context on every event: IP, user agent, request_id, actor user_id, actor role.

Recovery from corruption

The client_signoffs projection table is a derived view of the events log. If the projection drifts, it can be rebuilt by replaying events. The events themselves are the source of truth — and they're physically immutable.

Compliance caveat

The default declaration text is reasonable but not legally vetted. Before relying on this workflow for live lodgements, get a TPB-registered BAS or tax agent to review:

• The exact wording of the declaration
• The audit trail format and retention period (see backend/docs/SIGNOFF_RETENTION.md)
• Whether your practice's engagement letter template needs updating to reference the Frank workflow

Frank captures the data and the click; the legal sufficiency of the declaration is for you and your TPB-registered partner to confirm.