MANSOQ Knowledge
← Knowledge library

Finance & ZATCA

Confirm a statement line and distinguish advice, cash and local notices

Follow actual wide treasury controls, reference refusal, saved audit evidence and separate financial identities using an expressly fictional local example.

Current source · Current exact Polyclinic Facility Admin/root UI observations, normal authenticated API results and independent stored-record/audit inspection · 14 min read

Before you begin

1. Identify the advice and read each ledger separately

Open Revenue Cycle → Remittance, find the intended advice and use Show both ledgers. Read advice identity, date, issuer, debtor and payee before amounts. The synthetic example is900SAR: reported paid600 and reported adjustment300 are separate stored amounts. Before any cash import, the current UI displays a zero cash identity with a green Conserved badge. That is empty-ledger arithmetic and cannot prove that a real bank account has been checked or a zero bank balance is known.

Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.1234
Read advice before any fictional bank row exists · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.
  1. Advice distributed900: The advice contains reported paid600 and adjustment300, preserved separately in the stored advice allocation.
  2. Empty cash arithmetic: Zero and Conserved here are not evidence that a real account was checked.
  3. Beneficiary unknown: No beneficiary verification has occurred.
  4. Dual control incomplete: The fixture remains Draft and must not be treated as approved settlement instructions.

2. Inspect receipt and beneficiary state before confirmation

In Receipts with no payment notice, read the bank reference, allocated amount, value date and treasury status. A mock600SAR receipt was imported and allocated through the supported APIs; no cash-import or settlement authoring button exists on this page. The account remains Draft, beneficiary unknown and dual control incomplete. This exercise is interface teaching only, not an approved settlement account or actual credit.

After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.1234
Recognize the current facility-permission rendering mismatch · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.
  1. One unnotified receipt: Count of local allocated receipt groups requiring notice, not a bank balance.
  2. Mock allocation600: A deliberately fictional statement exercise.
  3. Return status unknown: The UI did not render the control for this Facility Admin even though the facility API permits it.
  4. Queue ownership unknown: A local receipt does not establish escalation ownership.
Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.1234
Read advice before any fictional bank row exists · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.
  1. Advice distributed900: The advice contains reported paid600 and adjustment300, preserved separately in the stored advice allocation.
  2. Empty cash arithmetic: Zero and Conserved here are not evidence that a real account was checked.
  3. Beneficiary unknown: No beneficiary verification has occurred.
  4. Dual control incomplete: The fixture remains Draft and must not be treated as approved settlement instructions.

3. Recognize the current scoped-permission UI issue

The observed existing Facility Admin can call the confirmation API and receives exact-reference validation, yet the current Remittance page shows Unknown with no confirmation button. Source inspection shows the page checks global hasPermission without facility object permissions. Preserve the mismatch for support. The following actual UI demonstration uses the existing root training operator; no permissions are changed and no general non-root treasury-role success is claimed.

After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.1234
Recognize the current facility-permission rendering mismatch · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.
  1. One unnotified receipt: Count of local allocated receipt groups requiring notice, not a bank balance.
  2. Mock allocation600: A deliberately fictional statement exercise.
  3. Return status unknown: The UI did not render the control for this Facility Admin even though the facility API permits it.
  4. Queue ownership unknown: A local receipt does not establish escalation ownership.
The existing root training operator opens the same fictional receipt; Confirm statement line is visible. No permissions were changed. This capture teaches the observed root control only and does not establish that every non-root treasury role is correctly rendered.1234
Locate the actual treasury confirmation control · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. The existing root training operator opens the same fictional receipt; Confirm statement line is visible. No permissions were changed. This capture teaches the observed root control only and does not establish that every non-root treasury role is correctly rendered.
  1. Exact fictional receipt: Identify the intended statement line before confirming.
  2. 600SAR allocation: This is the amount allocated against the local advice.
  3. Confirm statement line: The observed root has the action; the distinct Facility Admin UI mismatch is documented separately.
  4. Separate queue owners: Three unknown badges remain unresolved.

4. Open the exact statement-line confirmation

For an authorized operator whose UI displays the action, choose Confirm statement line on the intended receipt. The form deliberately does not reveal the imported statement reference. Check it against the independent actual bank statement in real operation. In this isolated demonstration only the retained fictional mock statement is used, with no real account or money.

The existing root training operator opens the same fictional receipt; Confirm statement line is visible. No permissions were changed. This capture teaches the observed root control only and does not establish that every non-root treasury role is correctly rendered.1234
Locate the actual treasury confirmation control · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. The existing root training operator opens the same fictional receipt; Confirm statement line is visible. No permissions were changed. This capture teaches the observed root control only and does not establish that every non-root treasury role is correctly rendered.
  1. Exact fictional receipt: Identify the intended statement line before confirming.
  2. 600SAR allocation: This is the amount allocated against the local advice.
  3. Confirm statement line: The observed root has the action; the distinct Facility Admin UI mismatch is documented separately.
  4. Separate queue owners: Three unknown badges remain unresolved.

5. Investigate a refused reference

A wrong mock reference produced the exact visible remittance_input refusal: Treasury confirmation must identify the recorded bank statement line exactly. The receipt remains unconfirmed and unnotified. Correct the reference using the source evidence; do not edit a confirmation flag or invent a bank transaction to clear the queue.

Actual root UI confirmation with a deliberately wrong fictional reference was refused: Treasury confirmation must identify the recorded bank statement line exactly. The600SAR receipt and unknown return state remained. This is a local reference guard, not real bank verification.1234
Read exact-reference refusal without changing the receipt · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Actual root UI confirmation with a deliberately wrong fictional reference was refused: Treasury confirmation must identify the recorded bank statement line exactly. The600SAR receipt and unknown return state remained. This is a local reference guard, not real bank verification.
  1. Wrong mock reference: The entered reference does not match the retained mock statement line.
  2. Confirmation action: This normal UI action produced the visible refusal.
  3. Exact refusal reason: Correct the source reference; do not mark the receipt confirmed manually.
  4. Receipt still unnotified: A refused confirmation does not clear the queue.

6. Submit the exact source reference and wait for the new result

Enter the exact independent statement-line reference and select Confirm statement line. The prepared screenshot shows the corrected fictional reference while the previous refusal is still displayed; it is not a saved result. In the next actual UI result the editor closes and Treasury confirmed appears. The separately observed normal API and stored audit receipt confirm the named root actor, exact reference and saved timestamp. The local example is not actual bank verification.

The corrected mock statement reference is entered and the normal confirmation action is enabled. The red message is retained from the previous failed attempt until a new result arrives; this frame is preparation, not confirmation success. The mock statement cannot substantiate real treasury confirmation.123
Prepare the exact fictional source reference · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. The corrected mock statement reference is entered and the normal confirmation action is enabled. The red message is retained from the previous failed attempt until a new result arrives; this frame is preparation, not confirmation success. The mock statement cannot substantiate real treasury confirmation.
  1. Exact retained mock line: KB-FICTIONAL-STATEMENT-20261018-LINE-001 comes from the fictional exercise record.
  2. Confirm current line: Use only after independently checking actual evidence in real operation.
  3. Previous refusal retained: This is the prior wrong-reference message, not the result of the corrected action.
Actual root UI confirmation of the exact fictional reference saved a named treasury attestation and displays Treasury confirmed. Independent persisted-record inspection verifies root actor, exact reference, confirmation timestamp and one audit event. There is still1 unnotified receipt: confirmation alone does not create a notice or send anything externally.1234
Verify the saved local treasury attestation · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Actual root UI confirmation of the exact fictional reference saved a named treasury attestation and displays Treasury confirmed. Independent persisted-record inspection verifies root actor, exact reference, confirmation timestamp and one audit event. There is still1 unnotified receipt: confirmation alone does not create a notice or send anything externally.
  1. Saved treasury badge: Persisted confirmation actor/time are independently verified.
  2. Still unnotified: A confirmation is not a local notice record or payer acknowledgement.
  3. Receipt identity retained: The original fictional bank reference remains unchanged.
  4. 600SAR retained: Confirmation does not change the imported amount.

7. Distinguish treasury confirmation from a notice record and delivery

Treasury confirmed still leaves1 receipt with no local payment notice. The supported payment-notice API subsequently created one local600SAR record. On reload the queue became0; duplicate identity reused the same record and another identity could not notify the same600 again. Independent inspection shows submitted_at remainsNULL. The source operation recorded locally without invoking transport; no NPHIES submission, payer delivery or acknowledgement is established.

Actual root UI confirmation of the exact fictional reference saved a named treasury attestation and displays Treasury confirmed. Independent persisted-record inspection verifies root actor, exact reference, confirmation timestamp and one audit event. There is still1 unnotified receipt: confirmation alone does not create a notice or send anything externally.1234
Verify the saved local treasury attestation · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Actual root UI confirmation of the exact fictional reference saved a named treasury attestation and displays Treasury confirmed. Independent persisted-record inspection verifies root actor, exact reference, confirmation timestamp and one audit event. There is still1 unnotified receipt: confirmation alone does not create a notice or send anything externally.
  1. Saved treasury badge: Persisted confirmation actor/time are independently verified.
  2. Still unnotified: A confirmation is not a local notice record or payer acknowledgement.
  3. Receipt identity retained: The original fictional bank reference remains unchanged.
  4. 600SAR retained: Confirmation does not change the imported amount.
After the supported local payment-notice API records one600SAR notice, the actual UI receipt-without-notice queue drops1→0. Independent DB inspection confirms exactly one notice, submitted_atNULL, and no transport. Duplicate identity deduplicated; a new identity covering already-notified cash was refused. This is local queue state only, not delivery, payer acceptance or real cash.123
Read the local notice queue after recording one notice · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. After the supported local payment-notice API records one600SAR notice, the actual UI receipt-without-notice queue drops1→0. Independent DB inspection confirms exactly one notice, submitted_atNULL, and no transport. Duplicate identity deduplicated; a new identity covering already-notified cash was refused. This is local queue state only, not delivery, payer acceptance or real cash.
  1. No locally unnotified receipt: The count changed after the local record was created.
  2. Owners remain unknown: Completing a local notice does not configure operational escalation.
  3. Local record queue: No external transport or payer response is shown here.

8. Interpret the final balances for finance and leadership

The final advice identity is900 distributed against900; the separate mock cash identity is600 distributed against600. Each conservation variance is0, while the300 difference between advice header and cash is a different question requiring attributed review. The stored advice retains600 reported paid and300 adjustment; never transfer that adjustment to the patient merely to balance cash. This allocation targets the advice only and does not update a claim cash projection. Unknown beneficiary, incomplete dual control and unknown queue owners remain visible.

Final UI readback retains advice900SAR conserved and a separate fictional cash600SAR conserved. Stored advice still reports paid600 plus adjustment300. The mocked bank allocation names the advice only; no claim cash projection occurred. The account remains Draft, beneficiaryUnknown and dual controlIncomplete. Neither green conservation badge establishes real bank evidence, legal collectibility or payer acknowledgement.12345
Interpret separate advice and cash identities after the exercise · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Final UI readback retains advice900SAR conserved and a separate fictional cash600SAR conserved. Stored advice still reports paid600 plus adjustment300. The mocked bank allocation names the advice only; no claim cash projection occurred. The account remains Draft, beneficiaryUnknown and dual controlIncomplete. Neither green conservation badge establishes real bank evidence, legal collectibility or payer acknowledgement.
  1. Advice900 conserved: Paid600 and adjustment300 remain separate facts.
  2. Fictional cash600 conserved: Cash allocation is600, not900; a conserved ledger is an arithmetic identity.
  3. Advice variance zero: Within-ledger conservation is not the300 difference between advice header and cash.
  4. Beneficiary still unknown: No real beneficiary approval or activation was asserted.
  5. Dual control incomplete: The exercise did not approve the fictional account.

Exact scope of this teaching result

One mocked statement row, one advice-only600SAR allocation, one actual root UI reference confirmation and one local notice were stored. The account was provisioned only as a validated Draft fixture because no bank-account-create UI/API is implemented. The legacy teaching package’s unavailable source assets and25 open gates are preserved. This demonstration does not qualify/publish that package, approve an account, verify a real beneficiary, move money, activate tax/fiscal services, send to NPHIES, prove payer acceptance or complete customer UAT.

Troubleshooting

The page says0 and Conserved before any cash evidence exists

Read it as the current arithmetic of an empty cash ledger. Check receipt identity, actual statement evidence and named treasury confirmation independently; do not turn the green badge into a bank-balance assertion.

Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.1234
Read advice before any fictional bank row exists · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. Before import the actual UI shows advice900SAR, cash ledger0SAR and Conserved, plus the explicitly fictional Draft account with Unknown beneficiary and Incomplete dual control. The zero is an empty-ledger arithmetic result, not proof of a known bank balance or bank receipt; the page warning separately says cash unknown until evidence arrives.
  1. Advice distributed900: The advice contains reported paid600 and adjustment300, preserved separately in the stored advice allocation.
  2. Empty cash arithmetic: Zero and Conserved here are not evidence that a real account was checked.
  3. Beneficiary unknown: No beneficiary verification has occurred.
  4. Dual control incomplete: The fixture remains Draft and must not be treated as approved settlement instructions.

A Facility Admin API call is permitted but the confirmation button is absent

Preserve the facility-specific response and role context for installation support. The current page checks global permission without facility object permissions. Do not broaden permissions solely to make a button appear.

After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.1234
Recognize the current facility-permission rendering mismatch · 2026-10-18Actual MANSOQ current frontend, isolated fictional Polyclinic, Chrome1728×921. After normal API import/allocation of fictional600SAR, this existing Facility Admin sees1 unnotified receipt with unknown treasury return status and no confirmation button. Normal API access for the same actor reaches exact-reference validation rather than403. The current page uses global hasPermission without passing facility object permissions, so this is a UI mismatch, not evidence of a backend treasury denial.
  1. One unnotified receipt: Count of local allocated receipt groups requiring notice, not a bank balance.
  2. Mock allocation600: A deliberately fictional statement exercise.
  3. Return status unknown: The UI did not render the control for this Facility Admin even though the facility API permits it.
  4. Queue ownership unknown: A local receipt does not establish escalation ownership.

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.