Skip to content

Super — Contributions lifecycle

Manual test plan for creating, validating, lodging, tracking, cancelling and amending super contributions through Beam, plus SuperStream notifications and AI diagnostics. Read How testing works first, and connect a company to Beam using the Connect plan.

Beam UAT only — real lodgements move real money

Lodging a contribution instructs the Beam clearing house to move super. Use the UAT environment only. A default super payment method must be set in Payroll → Settings before you can create contributions.

You will need: a company connected to Beam (UAT), employees with valid super fund details, at least one STP-lodged regular pay run (status Submitted/Success) that owes super, and a developer for the 🔧 notification cases.


A. Super Payments list

A1 — Status filter

Steps 1. Go to Payroll → Super (Payments). 2. Change the Status filter (All / Draft / Lodged / Paid / Cancelled).

✅ Pass if the list filters to the chosen status and resets to page 1.

❌ Fail if the filter has no effect or shows the wrong statuses — 🟠 Major.

A2 — Financial-year filter

Steps 1. Change the financial year filter in the top bar.

✅ Pass if the list and the summary cards re-scope to that FY (1 Jul–30 Jun) and the page resets to 1. A contribution whose period straddles 30 June / 1 July is bucketed by its pay date (not the period start), so it appears in the pay-date's financial year.

❌ Fail if the FY filter doesn't re-scope the list/cards, or a straddling-period contribution lands in the wrong FY — 🟠 Major.

A3 — Show archived toggle

Steps 1. Toggle Show archived.

✅ Pass if archived contributions appear (dimmed) when on and hide when off; the setting persists after reload; page resets.

❌ Fail if archived items show when the toggle is off (or vice versa) — 🟠 Major.

A4 — "Create" is disabled without a default payment method

Steps 1. Ensure Payroll → Settings has no default super payment method. 2. On the Super Payments list, look at the Create dropdown button.

✅ Pass if Create is disabled with a hint pointing to Payroll Settings, and a settings-gate banner offers Open Payroll Settings.

❌ Fail if you can start creating a contribution with no payment method — 🔴 Blocker (it can't be lodged).

A5 — "Create → From a pay run" / "Manual contribution"

Steps 1. With a payment method set, open the Create dropdown.

✅ Pass if it offers From a pay run and Manual contribution, opening the matching panel.

❌ Fail if either option is missing or opens the wrong panel — 🟠 Major.

A6 — Delete a Draft from the list

Steps 1. On a Draft row, click the trash icon and confirm.

✅ Pass if delete is offered only for Draft rows, a confirm dialog warns it cannot be undone, and it deletes with a toast.

❌ Fail if a non-Draft contribution can be deleted from the list — 🔴 Blocker.

A7 — "Lodge again" on a Cancelled row (clone guards)

Steps 1. On a Cancelled, non-archived row, open the row menu and click Lodge again. 2. Also try it on a Cancelled row that is archived, and on one whose pay run already has an active (Draft/Lodged) batch.

✅ Pass if

  • A fresh Draft is cloned — each employee's SGC and Salary-Sacrifice amounts copied exactly, payment status reset, linked to the original (from), and not marked an amendment; the original is archived.
  • It is blocked when the row is archived (message tells you to Unarchive first) or when the pay run already has an active super batch ("already an active super batch"). A cancelled row with no pay run is always clonable.

❌ Fail if "Lodge again" is offered on non-Cancelled rows, or the clone succeeds while an active sibling exists for the same pay run — 🔴 Blocker (duplicate lodgement).

A8 — Archive / Unarchive

Steps 1. Archive a Cancelled row, then turn on Show archived and Unarchive it.

✅ Pass if archive/unarchive work with toasts and the row moves in/out of the archived view.

❌ Fail if archive is offered on an ineligible status, or unarchive doesn't restore — 🟠 Major.

A9 — Amendment navigation chips

Steps 1. Find a contribution that is an amendment (or has amendments).

✅ Pass if an amendment chip links to the parent (from) contribution, and parent rows show an amendment-count badge.

❌ Fail if the amendment links go to the wrong contribution — 🟠 Major.

A10 — Summary cards & pagination

Steps 1. Review the Draft / Awaiting / Paid / Needs-attention summary cards; page through the list.

✅ Pass if the cards reflect backend totals across the FY scope (Paid green when >0, Needs-attention red when >0), and pagination changes page/size.

❌ Fail if card totals are wrong or pagination breaks — 🟠 Major.

A11 — Status / phase badge is correct in every state 🔧 partly dev-assisted

Steps 1. Observe the phase badge on contributions in each state (on the list and the detail screen). Use a developer to drive the Beam-side states.

✅ Pass if the badge reads:

  • Draft → "Drafting"
  • Lodged, Beam processing (Reconciled / SendingContributions) → "Processing" (money received by Beam, in flight)
  • Lodged, sent to fund → "Paid / Sent to fund"
  • Error → "Needs attention"
  • Lodged with a payment problem (dishonour / missing / under-payment / refund) → "Needs attention"
  • User-cancelled (or a Beam-reflected CANCELLED on a still-Lodged row) → "Cancelled", never "Needs attention"

❌ Fail if a resolved cancel shows as "Needs attention", or a refund/dishonour shows as Paid/Processing — 🟠 Major.


B. Creating a contribution

B1 — From a pay run

Steps 1. Create → From a pay run. Pick an eligible pay run.

✅ Pass if only STP-lodged runs (Submitted/Success) that still owe super and aren't already on an active contribution are listed; creating makes a Draft and opens it. When opened from a specific pay run, the run is pre-filled and locked.

❌ Fail if an ineligible run (Draft, not-lodged, or already-covered) is selectable, or "No pay runs awaiting super" isn't shown when there are none — 🟠 Major.

B2 — Manual (voluntary) contribution

Steps 1. Create → Manual contribution. Set period start/end, pick employees.

✅ Pass if period start must be before end (validation), employees are multi-selectable (with "N selected"), and creating requires at least one employee. It opens the new Draft.

❌ Fail if you can create with end ≤ start, or with zero employees — 🟠 Major.

B4 — Manual contribution prefills super from lodged pay runs and sets a due date

Steps 1. For an employee with STP-lodged (Submitted/Success) regular pay runs whose pay dates fall inside the period, create a Manual contribution covering that period. 2. Open the new Draft and check each employee's SGC amount and the contribution's due date.

✅ Pass if

  • Each selected employee's SGC is prefilled with the sum of their super from the STP-lodged regular pay runs in the period — Draft / not-yet-lodged runs and Finalise/Migration runs are excluded (they contribute $0).
  • The contribution shows a due date (about 7 business days after the pay date), so it can be tracked as on-time/overdue like a pay-run contribution.

❌ Fail if the prefill includes super from un-lodged runs, or the amounts are $0 when lodged runs exist, or no due date is set — 🟠 Major (🔴 Blocker if the prefilled amount is wrong money).

B3 — Create is guarded against double-submit

Steps 1. In either create panel, click Create Contribution and immediately click again.

✅ Pass if only one contribution is created (button disables while pending).

❌ Fail if two contributions are created — 🔴 Blocker.

B5 — Auto-create (and auto-lodge) super on STP submission 🔧 partly dev-assisted

Steps 1. In Payroll → Settings, set a default payment method and enable Auto-create super. Submit a regular pay run's STP that owes super. 2. Separately, also enable Auto-lodge super and submit another such pay run's STP.

✅ Pass if

  • Auto-create ON (auto-lodge off): a Draft super contribution appears automatically for that pay run (no manual Create), flagged as auto-created.
  • Auto-lodge ON: the auto-created batch is also lodged to Beam automatically.
  • Auto-create is skipped when: both toggles are off, no payment method (or method = None), the run's total super is $0, or an active batch already exists for that pay run (no duplicate). A run whose only prior batch is Cancelled does auto-create a fresh one.

❌ Fail if super is auto-created on a $0-super run, duplicates an existing active batch, or auto-lodges with no payment method — 🔴 Blocker (money-moving). Missing auto-create when enabled — 🟠 Major.

B6 — Due date uses the employer's state public-holiday calendar

Steps 1. Set a test company's state to VIC; create a contribution with pay date Fri 23 Oct 2026 and note the due date. 2. Change the company state to QLD (same pay date) and check again.

✅ Pass if the due date is pay date + 7 business days, counted on the employer's state calendar:

  • VIC → Wed 4 Nov 2026 (the 7 days cross Melbourne Cup, Tue 3 Nov — a VIC-only holiday — which is skipped).
  • QLD → Tue 3 Nov 2026 (Melbourne Cup is not a QLD holiday, so no shift).
  • A blank/unknown state falls back to the National calendar (= Tue 3 Nov); the full name "Victoria" behaves the same as "VIC".

❌ Fail if the due date ignores the company's state (hard-codes one calendar) or lands on a weekend/holiday — 🟠 Major.


C. Editing a Draft contribution

C1 — Inline edit SGC and Salary-Sacrifice amounts

Steps 1. Open a Draft contribution. Click an employee's SGC amount cell, change it, press Enter. Repeat for Salary Sacrifice.

✅ Pass if the amount saves inline (Draft only), the running total updates, and a non-numeric or negative value is rejected with a toast and reverts.

❌ Fail if amounts are editable on a non-Draft contribution, or a bad value is accepted — 🔴 Blocker (non-Draft edit) / 🟠 Major.

C2 — Add employees to the Draft

Steps 1. Click Add Employees, select eligible employees, enter SGC/SS, and add.

✅ Pass if only employees not already in the batch are offered; adding requires ≥1 selected; the running total updates.

❌ Fail if you can add a duplicate employee, or add with none selected — 🟠 Major.

C3 — Remove an employee (and delete-batch on last)

Steps 1. Remove an employee row (trash → confirm). Then remove the last remaining employee.

✅ Pass if removing one works; removing the last employee prompts "Delete this batch?" and deletes the whole contribution. Removal is rejected once the Draft has touched Beam (a Draft carrying a stored Beam response returns a "…Beam…" error rather than silently editing a money-moving batch), and removing a row that belongs to a different batch returns "not found".

❌ Fail if removing the last employee leaves an empty, un-lodgeable batch with no warning, or an employee can be removed from a Draft that already has a Beam response — 🔴 Blocker.

C4 — Edit period / pay date / description

Steps 1. Click Edit, change the period/description, save.

✅ Pass if it saves (dates required, start < end). When the contribution came from a pay run, the period fields are locked.

❌ Fail if pay-run-sourced fields are editable, or invalid dates save — 🟠 Major.

C5 — Download PDF (Draft shows DRAFT)

Steps 1. On a Draft, click Download PDF.

✅ Pass if a PDF downloads with a DRAFT banner (no payment instructions yet).

❌ Fail if the download fails or a Draft PDF shows real payment instructions — 🟠 Major.

C6 — Delete a Draft that has never touched Beam

Steps 1. On a Draft that has not been validated/lodged, delete it.

✅ Pass if it deletes cleanly.

❌ Fail if deletion is blocked for a truly-untouched Draft, or a Draft that has an unverified Beam response is silently deleted — 🔴 Blocker (the latter could orphan a money-moving action).


D. Validate & lodge with Beam

D1 — Pre-submit validation blocks bad employee data 🔧 partly dev-assisted

Steps 1. On a Draft, make one employee missing DOB and another with an invalid/blank state. Click Validate with Beam.

✅ Pass if validation is blocked before Beam is called, with clear per-employee errors (e.g. missing DOB, invalid state, missing fund ABN/USI/membership, SMSF missing ESA/bank). Fixing them clears the errors.

❌ Fail if a contribution with missing DOB or state is sent to Beam (it must never ship today's date as DOB or a defaulted state) — 🔴 Blocker.

D2 — Missing gender does NOT block

Steps 1. On a Draft, leave an employee's gender blank and validate.

✅ Pass if validation is not blocked by missing gender (it becomes a soft Beam warning, not an error).

❌ Fail if blank gender hard-blocks validation/lodgement — 🟠 Major.

D3 — Validate with Beam (clean pass)

Steps 1. On a Draft with valid employees, click Validate with Beam.

✅ Pass if a toast reports passed / passed-with-warnings, and the action button then offers Lodge with Beam.

❌ Fail if a clean validation doesn't unlock Lodge, or errors aren't listed clearly — 🟠 Major.

D4 — Editing after a clean validate makes it stale

Steps 1. After a clean validate, change an amount or add/remove an employee.

✅ Pass if the button reverts from Lodge back to Validate (the earlier validation is now stale).

❌ Fail if you can lodge a batch you changed after validating — 🔴 Blocker.

D5 — Validate is blocked with no employees

Steps 1. On a Draft with no employees, look at Validate.

✅ Pass if Validate is disabled with a hint to add employees.

❌ Fail if you can validate an empty batch — 🟠 Major.

D6 — Lodge with Beam

Steps 1. After a clean validate, click Lodge with Beam and confirm in the dialog.

✅ Pass if the confirm dialog states the payment method and any warning count; on confirm the contribution moves to Lodged, a process id is shown, and the validation banner clears.

❌ Fail if lodging fails silently, or lodges despite blocking errors — 🔴 Blocker.

D7 — Lodge is safe on timeout (no double-send) 🔧 Needs developer setup

Steps 1. Ask a developer to make the lodge request time out after Beam actually received it.

✅ Pass if the app does not blindly retry; it re-checks with Beam and reconciles the contribution to Lodged (not a second submission).

❌ Fail if a timeout causes a duplicate contribution — 🔴 Blocker.

D8 — Terms-and-conditions re-accept 🔧 Needs developer setup

Steps 1. Ask a developer to make Beam return the T&Cs must be re-accepted result on lodge.

✅ Pass if a sticky "Re-accept Beam terms" banner appears; clicking it re-opens Beam terms; lodgement is not silently marked done.

❌ Fail if a T&Cs rejection is shown as a generic failure or a false success — 🟠 Major.

D9 — Validate / Lodge is blocked when Beam registration is incomplete 🔧 Needs developer setup

Steps 1. On a company that is mid-onboarding (Setup incomplete / not yet Registered), open a Draft and try Validate with Beam / Lodge with Beam.

✅ Pass if the action is refused with a "…not registered…" message and nothing is sent to Beam.

❌ Fail if a batch is validated or lodged for a company whose Beam registration is incomplete — 🟠 Major.

E1 — Check status

Steps 1. On a Lodged/processing contribution, click Check status.

✅ Pass if it queries Beam and updates with a toast "Beam status updated: X"; each employee's payment status updates too. (Hidden for Cancelled and for manually-marked contributions.)

❌ Fail if Check status doesn't reflect Beam's current status — 🟠 Major.

E2 — Cancel a genuinely-lodged contribution

Steps 1. On a Lodged contribution (real Beam lodge), click Cancel Lodge and confirm.

✅ Pass if Cancel is offered only for genuinely Lodged contributions (not Error/Paid/Processing/Cancelled/manual), and cancelling moves it to Cancelled. For Direct Debit, the dialog shows the 3:30pm AEST cutoff and different copy once passed.

❌ Fail if Cancel is offered when it shouldn't be, or succeeds after money already dispatched with no warning — 🔴 Blocker.

E3 — Cancel that Beam rejects — exact friendly copy per reason 🔧 Needs developer setup

Steps 1. Ask a developer to make Beam reject a cancel with each reason: already dispatched, already paid/received, already cancelled, not found (404), and an unknown message.

✅ Pass if the app re-checks Beam and translates each to friendly copy (the raw processId=… string is never shown):

  • Dispatched (ALREADY_DISPATCHED / TOO_LATE_TO_CANCEL) → mentions "dispatched" + guidance about a refund.
  • Paid/received → tells you to contact the fund about the payment directly.
  • Already cancelled → "already cancelled" + suggests a refresh (it reflects Beam's status without fabricating a user-cancel).
  • Not found → "doesn't recognise…" + contact support.
  • Unknown message → shown verbatim (no guessed copy on a destructive action).

❌ Fail if the UI says "Cancelled" while Beam still has it sent-to-fund, or shows the raw Beam string — 🔴 Blocker.

E4 — "Lodge again" / retry a rejected batch 🔧 Needs developer setup

Steps 1. Ask a developer to put a contribution into Error (rejected by Beam). Click Lodge again.

✅ Pass if it re-checks Beam: if Beam actually has it, it reconciles to Lodged; if not, it resets to Draft ready to re-lodge (same batch, no duplicate).

❌ Fail if retry creates a duplicate contribution for the period — 🔴 Blocker.

E5 — Mark as Lodged (manual, no Beam)

Steps 1. On a Draft, use Mark as Lodged.

✅ Pass if the confirm copy stresses this does NOT submit anything to Beam (and mentions you can revert it to Draft afterwards — see E6); the contribution shows as manually lodged. It is not enrolled in Beam auto-polling (there's no Beam batch to track).

❌ Fail if a manual mark triggers a real Beam submission or Beam status polling — 🔴 Blocker.

E6 — Revert a manual lodge to Draft

Steps 1. On a manually lodged contribution (no Beam lodge date), use Revert to Draft.

✅ Pass if revert-to-Draft is offered only for manual lodges (never for a real Beam lodge) and returns it to Draft.

❌ Fail if a real Beam-lodged contribution can be reverted to Draft — 🔴 Blocker.

E7 — Create an amendment for failed employees 🔧 Needs developer setup

Steps 1. Ask a developer to mark some employees in a lodged contribution as failed/refunded. 2. Click Create amendment for N failed.

✅ Pass if a new Draft amendment is created containing only the failed employees, linked to the original.

❌ Fail if the amendment includes already-successful employees, or isn't linked to the parent — 🔴 Blocker (double-paying successful members).

E8 — Overdue / approaching-due banners

Steps 1. View a contribution whose due date is near or passed (and not Paid/Cancelled). Test both a pay-run contribution and a manual/voluntary one.

✅ Pass if an overdue banner shows past the due date, and an approaching-due warning shows within ~3 days. Manual contributions now carry a real due date (see B4), so they classify on-time/overdue the same way.

❌ Fail if an overdue contribution (pay-run or manual) shows no warning — 🟠 Major.

E9 — A refund/rejection is still money owed (Outstanding → Overdue, not Paid) 🔧 Needs developer setup

Steps 1. On the super overview / summary, check the totals for a member who was refunded / rejected (super still owed), both before and after the due date, versus a genuinely sent-to-fund member.

✅ Pass if a refunded/rejected amount counts as Outstanding (SG still owed) — classified on-time before the due date and overdue once past it — and is excluded from "paid to funds". For example: a $720 refund due in the future → Outstanding $720 / Overdue $0 / Paid $0; a $2,500 refund past due → Overdue $2,500 (overdue-employee count 1); a genuine sent-to-fund $600 → Paid $600 / Outstanding $0.

❌ Fail if a refunded amount shows as Paid, or never becomes Overdue past its due date — 🟠 Major (super-guarantee-charge exposure).


F. Payment details & SuperStream notifications

F1 — Payment instructions & copy buttons

Steps 1. Open a Lodged/Paid contribution. The Payment details panel is open by default on lodged/paid batches (use Hide details / Payment details to collapse/expand). Use the copy buttons (BSB, account, biller/PRN/CRN, etc.).

✅ Pass if the panel is already expanded on a freshly lodged/paid contribution (no click needed), matches the payment method (Direct Debit vs EFT/BPAY), each copy button copies the right value (check icon confirms), and multi-payment splits show per organisation. Your collapse/expand choice is remembered.

❌ Fail if a copy button copies the wrong value, the panel shows the wrong method's fields, or it starts collapsed on a lodged/paid batch — 🟠 Major.

F2 — Payment exceptions keep the batch Lodged (over-payment is informational) 🔧 Needs developer setup

Steps 1. Ask a developer to simulate each exception in turn: DD dishonour, no/missing payment, under-payment (and pending under-payment), over-payment (and pending over-payment).

✅ Pass if each keeps the contribution Lodged (a payment problem, not a system Error) with the matching status — Dishonoured / MissingPayment / UnderPayment / OverPayment. A red make-up payment card (alternate EFT/BPAY details + copy buttons) appears for shortfalls. Over-payment is shown as informational (blue) with no "action required" alert (nothing is owed). An unknown/blank exception type is treated as a genuine system Error.

❌ Fail if a payment-side exception flips the whole contribution to Error, or an over-payment raises an action-required alert — 🔴 Blocker / 🟠 Major.

F3 — SuperStream code hints in the activity timeline 🔧 Needs developer setup

Steps 1. Ask a developer to send Beam notifications with different SuperStream codes (e.g. member-not-found SUPER.GEN.GEN.21, over-payment .7).

✅ Pass if each known code shows an actionable "what to do" hint with the right tone (error/warning/info — over-payment is info/blue), the fund's message verbatim, and the error-code badge.

❌ Fail if codes show as raw text with no guidance, or the wrong tone — 🟠 Major.

F4 — Refund handling & refund-implying codes 🔧 Needs developer setup

Steps 1. Ask a developer to send contribution responses covering: (a) an explicit refund for one member; (b) a member-not-found code SUPER.GEN.GEN.21 and a no-longer-a-member code SUPER.GEN.GEN.22 with no RefundAmount param; (c) a refund with a null context id; (d) a refund whose context id matches no member.

✅ Pass if

  • The explicit refund flips only that member to Refunded with a date.
  • Codes .21 and .22 flip only that member to Refunded with a RefundedDate even though no RefundAmount is present (these codes imply a refund).
  • A null context id applies the refund at the batch level (all members).
  • A context id that matches no member leaves all members untouched and is logged (never blanket-applied).
  • Non-refund codes (payment-not-reconciled / contributions-not-accepted / TFN-required) do not imply a refund.

❌ Fail if a refund is dropped silently, an unattributable refund is blanket-applied, or a member-not-found code is masked instead of refunding — 🔴 Blocker.

F5 — Activity timeline records every attempt (with codes)

Steps 1. Validate a batch (clean, and again with a warning), then attempt a lodge that Beam rejects (ask a developer). Dismiss the on-page banners, then open the activity timeline.

✅ Pass if

  • Lifecycle / payment / validation / notification events are interleaved with coloured severity dots, and a "Show N processing updates" toggle expands routine status pings.
  • Every validate/lodge attempt is recorded and survives dismissing the banner: a Passed, a Passed-with-warnings (e.g. "1 warning", expandable to the detail such as "Gender missing / WRN048"), and a Failed lodge that shows the Beam error code + message inline (e.g. "ERR126 — you have not accepted the most recent terms and conditions") — not a bare "Error" row.

❌ Fail if the timeline is empty when events exist, a failed lodge shows only "Error" with no code/message, or a dismissed banner loses the audit entry — 🟠 Major.

F6 — Status stepper

Steps 1. Look at the status stepper on a Lodged/Paid contribution.

✅ Pass if it reflects the lifecycle; a terminal-bad state shows a red node; it is suppressed for Draft/Cancelled/failed.

❌ Fail if the stepper shows a wrong or misleading stage — 🟠 Major.


G. AI diagnostics (Super Diagnostic panel)

G1 — Diagnosis appears on a failed/rejected contribution 🔧 Needs developer setup

Steps 1. On a contribution with failed employees or a sync rejection, view the Super Diagnostic panel.

✅ Pass if it lazily loads diagnosis cards (skeleton while loading), shows a confidence badge, and renders nothing when there are no diagnoses. An error state offers Retry.

❌ Fail if the panel crashes or shows diagnoses for a healthy contribution — 🟠 Major.

G2 — Apply fix

Steps 1. On an applicable diagnosis card, click Apply fix.

✅ Pass if it applies with a toast and a hint to lodge an amendment when ready; a refusal shows a warning with the reason.

❌ Fail if Apply fix silently changes nothing or corrupts data — 🔴 Blocker.

G3 — Dismiss

Steps 1. Click Dismiss on a diagnosis card.

✅ Pass if the card hides with a toast and does not reappear on refresh.

❌ Fail if a dismissed diagnosis keeps coming back — 🟠 Major.


H. Behind-the-scenes reliability (Beam notifications & status) 🔧 Needs developer setup

These verify the automatic pipeline. A developer simulates Beam notifications; you confirm the result on the contribution screen.

H1 — Status notification updates the batch

Steps 1. Ask a developer to send a STATUS notification for a lodged batch.

✅ Pass if the contribution and its employees update to the mapped status; a terminal status propagates to the unpaid employees with the correct send-to-fund date.

❌ Fail if the notification doesn't correlate to the batch, or updates the wrong one — 🔴 Blocker.

H2 — Exception system-error vs payment-side split

Steps 1. Ask a developer to send an unknown/blank exception type, then known payment-side ones: dishonour, missing payment, under-payment (and pending under-payment), over-payment (and pending over-payment).

✅ Pass if the unknown/blank type flips the contribution to Error (system failure), but every payment-side exception keeps it Lodged with the matching payment flag — and over-payment is treated as informational (no Error, no action-required alert). See also F2 for the UI surface.

❌ Fail if a payment-side exception wrongly flips to Error, an over-payment raises an action-required alert, or an unknown type is ignored — 🔴 Blocker.

H3 — Duplicate notification is idempotent

Steps 1. Ask a developer to deliver the same Beam notification twice.

✅ Pass if it is processed once — no duplicate history rows, no double status changes.

❌ Fail if the same notification is processed twice — 🟠 Major.

H4 — Notifications are per-company (not by ABN)

Steps 1. With two companies connected, ask a developer to send notifications for each.

✅ Pass if each notification lands on the correct company's contribution.

❌ Fail if notifications for one company affect another, or the pipeline returns nothing — 🔴 Blocker.

H5 — Auto-poll keeps checking until settled

Steps 1. After a real lodge, leave the contribution and ask a developer to advance Beam through processing states over time.

✅ Pass if the background auto-poll keeps updating the status until it settles (it must keep polling through mid-flight "Reconciled", stopping only when genuinely complete/cancelled/error). When a batch first enters an action-required state (dishonour / missing / under-payment / refund / failed), it raises an alert — an "Action required: your super payment needs attention" email plus an audit entry — once on the transition, not every poll.

❌ Fail if auto-poll stops too early (leaving a stale status), never alerts on action-required, or re-alerts on every poll — 🟠 Major.

H6 — A manual mark-as-lodged and a user cancel are not auto-polled

Steps 1. Mark a contribution as lodged manually (no Beam) and leave it. 2. Separately, lodge to Beam then Cancel it, and leave it.

✅ Pass if neither is picked up by the Beam auto-poll: a manual mark is never enrolled (no Beam batch to check), and a user Cancel disenrols it — so the sweep does not fire a spurious "action required" alert on the user's own cancellation.

❌ Fail if the poller queries Beam for a manual contribution, or a user-cancelled batch raises an action-required alert — 🟠 Major.