When Nagaris composes a BAS workpaper, its engine checks the ledger and raises queries about what it finds. Queries come in two kinds:
Exceptions: something specific to this period that needs a reviewer's attention, like a credit note that needs chasing.
Confirmations: a standing position the engine restates on every run for this client, such as the reporting basis, the super guarantee rate, or BAS-excluded coding sitting outside the calculation by design. These aren't new findings, they're what a reviewer is asserting by signing off the workpaper.
A cell containing a tax file number raises its own kind of exception: Nagaris masks the TFN and queries it rather than composing it in the open. See "How Nagaris masks tax file numbers in workpapers" for what triggers a mask, what still halts a workbook, and how to release a reviewed value.
The BAS list, the workpaper run history and a client's BAS card all show a "to clear" or "Queries" count. That count is exceptions only, confirmations are excluded so the number reflects real work left to do rather than a permanent floor that never reaches zero.
Open a BAS workpaper's findings to see:
Exceptions to clear, listed first. If the engine found none, the workpaper shows a confirmation that nothing needs clearing for this period.
Standing confirmations, folded under a collapsible "what signing this asserts" section below the exceptions. Expand it to see each confirmation and the reasoning behind it.
Clearing exceptions is what a reviewer needs to act on before approving a run. Standing confirmations stay visible for context but don't count against the workpaper as outstanding work.
Clients with an FBT instalment obligation get two extra queries tied to label F1:
A standing confirmation reading F1 copied from ATO notice, not composed, on every run for that client. It's there to remind a reviewer that F1 isn't calculated from the ledger like the other labels, it's whatever was entered from the ATO's instalment notice.
An exception if the FBT instalment profile is turned on but F1 hasn't been entered for the period. The workpaper still composes and shows the rest of the figures; the exception just flags that F1 needs to be chased before the return is signed off.
Every query also carries a stable ID, built from the rule that raised it and the specific thing it's about, such as an account code, a document, or a reconciliation row. That ID stays the same across composes for as long as the underlying issue does, which is what lets your replies carry forward when you recompose (below).
Each query has a REPLY cell (or CARISMA REPLY, for packs reviewed by Carisma) where you type your explanation before signing off. Your reply is tied to the query itself, not to its row position, so it survives edits elsewhere on the pack.
Recomposing a workpaper, whether to pull in a newly reconciled transaction or fix something upstream, doesn't throw away work already done:
Before rebuilding the workpaper, Nagaris reads every reply on the current pack and reapplies each one to the matching query in the new pack.
A carried reply shows a note reading "carried from <hash> <date>", so you can tell at a glance that it came from an earlier run rather than being typed on this one.
If the figures behind a query changed since you replied (for example, a document moved into or out of the period), the query reopens and shows your earlier reply next to the new figures, so you can decide whether it still holds.
If a query can't be matched to anything in the new pack, for instance because the issue it was about no longer exists, your reply isn't dropped. It moves onto a single carry-forward report query so nothing is lost.
Rows you added yourself, rather than ones the engine generated, carry forward as they are.
If a recompose is checked against a carry file from a different BAS period, that period's carry-forward is skipped, and the pack notes it against that one query. The rest of the compose still completes normally.
