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
.21and.22flip only that member to Refunded with aRefundedDateeven 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.