Accounts receivable workflow: obligation, receipt, allocation, and review

01

Define the receivable and its source

A receivable records an amount owed by a customer under a defined business event. The source may be a supported invoice or another controlled operational record. The receivable should identify the customer, currency, amount, dates, status, and source context needed for review. It should not be an unexplained balance typed directly into a dashboard.

Keep document identity separate from journal identity. The receivable explains the customer obligation; the journal represents its accounting consequence where the organization’s configured workflow posts it. Linking them is useful, but collapsing them can make operational correction and accounting reversal difficult to reason about.

02

Record receipts before deciding what they settle

A receipt records that value was received. Allocation records which open obligations that receipt settles. Keeping these concepts distinct supports partial payment, one receipt applied across multiple obligations, and an unapplied amount that requires later review.

The system should prevent allocation above the available receipt or the open receivable balance. Repeated allocation requests need idempotent behavior. Reversal should preserve the original allocation history and explain the restored balance rather than deleting evidence.

03

Use aging as a review tool

Aging groups open balances by a defined date and bucket policy. It helps teams prioritize review, but it does not explain every dispute or collection decision. The report should state which date drives aging, which records are included, and how unapplied receipts or credits are treated.

Reconcile aging totals to the underlying open receivables and, where supported, to the related general-ledger control account. Investigate records that appear in one view but not the other. A dashboard total without a drill path is not sufficient evidence for close or collection work.

04

Protect customer and financial boundaries

Receivable, receipt, and allocation actions should require explicit permissions. Tenant context must come from the authenticated server-side session rather than a client-submitted organization identifier. Cross-tenant attempts should fail without disclosing whether a customer or document exists elsewhere.

Posted journals and period locks need their own controls. If an operational receivable changes after a related posting, the accounting correction should use an explicit reversal or adjustment path. Silent edits can break both audit history and reconciliation.

• Derive open balances from receivable and allocation records.
• Prevent over-allocation and duplicate processing.
• Preserve reversal history and actor context.
• Reconcile aging to source records and supported ledger totals.
• Keep customer and financial access tenant-scoped.

05

Zivanox scope and evaluation questions

Zivanox provides an operational finance foundation with customer obligations, receipts, allocations, balances, aging where implemented, balanced journals, period control, and reporting. It connects supported Finance records to the same governed organization context used by operational modules.

This is not a claim of bank feeds, payment processing, collection automation, tax filing, statutory reporting, or jurisdiction-specific accounting certification. Evaluation should confirm the source documents, currencies, allocation rules, reporting needs, and external banking or filing responsibilities your organization requires.

Use representative exceptions during evaluation: one partial receipt allocated across open obligations, a duplicate allocation request, a receipt larger than the remaining balance, a reversal in an open period, and an attempted change after lock. Reconcile customer balance, aging, receipt state, allocation history, and any configured journal consequence after each case. The objective is not to reproduce external banking behavior but to prove that supported operational records remain balanced, attributable, permission-bound, and explainable when the payment story is more complicated than one invoice followed by one receipt.