Help

Dental Billing and Payment Workflow

Direct answer

Create the bill from completed visit procedure items or approved manual items, verify quantity, unit price, tooth, discount, and patient, then record payment or apply an existing prepayment. A partial balance becomes a receivable. Use explicit refund, adjustment, collection, and write-off actions with reasons; never create a negative bill or silently rewrite the original financial event.

Dental Ark records local operational finance data. It does not decide treatment necessity, insurance coverage, tax treatment, coding rules, refund authority, payment-processing settlement, or accounting compliance. The clinic must approve its charge catalogue and reconciliation policy.

Configure charge items

Set up reusable charge items with a name, category, default price, tooth-specific flag, chair requirement, and note. Default values reduce typing, but the operator must verify the actual procedure and price at checkout.

Charge field	Review
Item name	Clear treatment or service description
Category	Clinic-approved finance grouping
Tooth code	Correct FDI reference when applicable
Quantity	Positive count only
Unit price	Approved non-negative amount
Source procedure	Trace to completed visit work when available
Note	Relevant context without unnecessary clinical data

The service rejects an empty bill, non-positive quantity, negative unit price, negative discount, negative paid amount, and discount above subtotal.

Build the bill

Checkout can start from completed visit items. Review every imported procedure, add only authorized manual items, and remove duplicates before saving.

The calculation is:

subtotal = sum(quantity × unit price)
total = subtotal − discount
unpaid = total − accepted payment − allocated prepayment

The stored bill status becomes unpaid when nothing has been received, partial when some amount remains, and paid when the balance reaches zero. A status is the result of ledger events; do not change it as a cosmetic shortcut.

Record payment

Select the actual payment method used by the clinic and enter the amount received. Payment methods can include cash, card, bank transfer, mobile payment, or another configured operational label. Record the external receipt or terminal reference in a safe note when policy requires it.

Scenario	Correct action
Full payment	Record the exact received amount
Partial payment	Record amount; retain the receivable
Existing prepayment	Allocate no more than available credit and amount due
New overpayment	Verify the generated remaining prepayment
Later debt payment	Record against the open bill/receivable
Wrong amount	Use supported correction event and reason

Never record card or bank details that the application does not need. Dental Ark records the payment event; it is not the card processor or bank settlement system.

Use prepayments safely

A prepayment belongs to a patient, has an original amount, remaining balance, payment method, purpose, time, and status. Allocate it to a bill only with authorization and never above the remaining prepayment or amount due.

Checkout can combine a cash or other payment with a prepayment allocation. Supported overpayment handling can create a new prepayment for the patient. Verify the resulting ledger and balance after the transaction.

Manage receivables

Unpaid amounts are represented as receivables linked to the bill and patient. The workflow supports debt payments, collection notes, collection status, write-off, and closure conditions.

Collection notes should include method, result, reason or note, and next contact time. Avoid copying unrelated diagnoses into finance notes. A receivable can close when its remaining amount reaches zero or through an authorized write-off; the historical bill remains part of the ledger.

Refunds, adjustments, and write-offs

The previous Help page incorrectly told users to create a negative bill for a refund. Do not do that. Dental Ark implements explicit financial events:

Refund: returns value from a supported bill or finance source and records method and reason.
Adjustment: adds a signed correction with explanation and authorization.
Write-off: closes an approved remaining receivable with a reason.
Collection closure: closes collection workflow only when its conditions are satisfied.

Event	Preserve	Never use it to
Refund	Original bill, amount, method, reason	Delete the original sale
Adjustment	Signed delta and explanation	Hide an unexplained discrepancy
Write-off	Receivable, amount, approval reason	Pretend money was received
Collection note	Contact evidence and next action	Store unnecessary clinical narrative

Reconcile the resulting patient ledger after every correction.

Finance review and export

The finance workspace can filter and export ledger rows as CSV. Current implementation also supports Professional finance, daily-close, bill, receipt, or clinical PDF paths where exposed by the interface. PDF export is a Professional catalog capability; CSV is not a replacement for the source database.

Before export, set the intended date and finance filters. Verify that the output contains the expected payment, prepayment, refund, adjustment, and write-off rows and no unrelated patient data. Store the file in an approved accounting location.

For daily operations, pair this page with the clinic daily workflow.

Daily reconciliation

Compare Dental Ark events with external evidence:

cash drawer;
card-terminal settlement;
bank transfer statement;
mobile-payment settlement;
approved refund evidence;
prepayment balances;
signed adjustments and write-offs.

The daily-close result should explain every difference. Do not force the application total to match by adding an unreasoned adjustment.

Community and Professional

Community includes billing, patients, appointments, visits, records, assets, and backup within documented capacity limits. Professional adds unlimited records and PDF export. A bill or payment does not become more correct because Professional is active; edition boundaries affect capacity and delivery formats.

Billing QA checklist

Patient and visit are correct.
Bill contains at least one valid item.
Completed procedures and manual charges are not duplicated.
Tooth, quantity, unit price, discount, and total are reviewed.
Payment method and amount match external evidence.
Prepayment allocation stays within balance and amount due.
Partial balances create a visible receivable.
Refunds, adjustments, and write-offs use explicit events and reasons.
Daily totals reconcile with cash, terminal, bank, and mobile sources.
Exports contain only authorized data.
A validated backup is created after material finance changes.

FAQ

Can I edit a paid bill silently?

No workflow should silently rewrite financial history. Use the supported refund, adjustment, payment, receivable, or write-off action that expresses what happened and preserves audit context.

How should I handle a refund?

Use the explicit refund action with the source, amount, payment method, and reason. Do not create a negative bill.

Is PDF export available in Community?

No. The current catalog assigns dental PDF export to Professional. Community still retains the local billing and backup workflow within capacity limits.

Direct answer and acceptance boundary

For “Dental Billing and Payment Workflow”, the short answer is: Create itemized Dental Ark bills, apply discounts and prepayments, record partial or full payments, manage receivables, refunds, adjustments, and finance exports. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Dental Ark.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Dental Billing and Payment Workflow

Treat “Dental Billing and Payment Workflow” as a separate acceptance gate for “Dental Billing and Payment Workflow”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Create itemized Dental Ark bills, apply discounts and prepayments, record partial or full

Verify “Create itemized Dental Ark bills, apply discounts and prepayments, record partial or full payments, manage receivables, refunds, adjustments, and fina” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Direct answer

For “Direct answer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Configure charge items

Use “Configure charge items” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Build the bill

When “Build the bill” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Record payment

Close “Record payment” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Use prepayments safely

Treat “Use prepayments safely” as a separate acceptance gate for “Dental Billing and Payment Workflow”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Manage receivables

Verify “Manage receivables” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Refunds, adjustments, and write-offs

For “Refunds, adjustments, and write-offs”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Finance review and export

Use “Finance review and export” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Dental Billing and Payment Workflow	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Create itemized Dental Ark bills, apply discounts and prepayments, record partial or full payments, manage receivables,	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Configure charge items	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Build the bill	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Record payment	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: