Billing

Record an account advance and return it in separate credit entries

Follow the actual saved 100 SAR advance, 30 SAR partial return, remaining 70 SAR return, printable receipt and completed account closure.

Current source · source reviewed · 10 min read

Before you begin

Use fictional data in an isolated training environment for this example; no real cash, bank, insurer or tax transaction occurs.
Use an existing role with payment-reconciliation write/read permission and an authorized active collection location. Billing Officer is not included in the audited permission catalogue.
The account is active and this example has no charge or invoice. Its initial creation was authenticated API fixture setup; account creation UI was not tested.
Account advance/credit records and a printable billing refund receipt do not establish a canonical fiscal correction document.

1. Start an advance on the intended account

Open the active account and select Advance/Receipt. Select Cash, Advance and Patient, confirm the configured collection location, and enter 100 SAR as Amount Paid and Amount Received. Record a clear teaching-only note. The actual UI saved the advance without an invoice link.

Record an account advance without an invoice · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The existing Facility Admin records a synthetic 100 SAR cash advance at the teaching cashier, without an invoice. No actual cash or bank movement occurs.

2. Verify the saved advance and account position

Open the Payments tab. The account displays the original 100 SAR advance, Total Paid 100 SAR, Billed zero and Amount Due -100 SAR. In this unbilled teaching account, the negative amount represents recorded overpayment; it is not an unpaid invoice or evidence of bank credit.

Verify the saved account advance · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The UI-created 100 SAR advance appears without an invoice link and gives the unbilled account a -100 SAR amount due. Later independent readback confirms the original advance record persists alongside its separate partial return.

3. Record a separate partial return

From the account menu select Record Credit Note. Select Cash and Advance, enter Refund Amount 30 SAR, retain the collection location and describe the partial return. The actual UI saved a separate record. Its stored amount is positive 30 with is_credit_note=true; the ledger displays -30 SAR. The original advance remains intact.

Record a partial return of an account advance · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The real Record Credit Note form records a synthetic 30 SAR partial return of the advance. This account-level billing record does not establish a fiscal correction document or an actual cash refund.

Verify the partial return and remaining credit · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The account ledger retains the 100 SAR advance and displays the 30 SAR credit as -30 SAR, leaving 70 SAR net recorded funds and -70 SAR amount due. Database readback confirms positive stored amount30 plus is_credit_note=true.

4. Inspect the refund record and printable receipt

Open the credit entry to verify amount, method, collection location, author and note. The current implementation retains generic Kind=Deposit even on this refund; read the credit-note flag, refund heading and signed ledger together. Print Receipt opens the current HTML preview with payment ID, generator and location. Only this preview was observed; no printer or external delivery was tested.

Read the saved refund record and authorship · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The separate refund view confirms 30 SAR, Cash, Advance, the teaching collection location and Facility Admin authorship. Generic Kind remains Deposit in this implementation; direction also depends on the credit-note flag and signed ledger display.

Inspect the printable refund receipt · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. The current printable refund receipt includes its payment ID, synthetic patient, 30 SAR amount, generator and location. Only the HTML preview was observed; no printer or external file delivery was used, and no fiscal correction document is implied.

5. Return the remaining amount as its own record

After the partial return, independent readback confirms 70 SAR remains recorded. The example then uses Record Credit Note again for the remaining 70 SAR, with a separate note. The resulting ledger retains all three records: +100, -30 and -70 SAR. Net recorded funds and amount due become zero; no invoice was created.

Verify the full return without losing history · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. After a separate 70 SAR remaining return, the ledger retains all three entries: 100 SAR advance, -30 SAR partial credit and -70 SAR remaining credit. Net recorded funds and account balance are zero; no invoice or real money movement exists.

6. Close only with the correct disposition

For the now fully returned teaching account, select Settle & Close and deliberately choose Closed Completed. The dialog initially defaults to Closed Bad Debt. Actual UI closure saved inactive status and an end date while preserving the original advance and both credit entries. Independent database readback confirms zero net totals and closed_completed state.

Verify closure after the teaching advance is fully returned · 2026-10-18. Current audited app in isolated synthetic Polyclinic training. Actual UI Closed Completed saved inactive account status, an end date, zero net totals and all three advance/credit entries. Independent database readback confirms the final state; initial account creation alone was normal-API fixture setup.

Use canonical finance for RCM insurer receipts

The audited backend refuses insurer receipts through the legacy payment route when the account is RCM-managed or has a canonical insurance invoice. Such receipts belong to the canonical advice, confirmed bank receipt, settlement and payment-notice workflow. Do not relabel the issuer as Patient to evade that refusal. This example uses explicitly synthetic patient/cashier entries only.

What this example leaves open

This is one current Polyclinic Facility Admin observation. Other roles, partial allocations, real payment methods, transfers, cancelled receipts, linked reversals, canonical refunds and fiscal correction documents need their own evidence. No real cash movement, bank credit, payer adjudication or tax filing was verified.

Troubleshooting

The ledger shows a negative credit but the database amount is positive

Direction is represented by is_credit_note; account synchronization subtracts valid credit-note amounts and the UI applies the sign. Do not change stored amounts to negative to mimic the display.

A credit entry is being mistaken for a fiscal credit note

Identify the actual resource and original fiscal document. This example has only account-level payment-reconciliation records and a refund receipt; no invoice or electronic correction document exists.

Source evidence

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