Receivables: counterparties, open items and receipts

Receivables are what companies, agencies and OTAs owe a workspace’s properties on account (ADR 0051). Open Receivables in the workspace navigation; it needs receivables.read (or receivables.manage), built in for administrators and accounting. A member limited to selected properties never holds these permissions: receivables span the workspace’s properties. Billing a company at check-out is the desk’s, with receivables.transfer (below), also for a desk limited to its properties.

Counterparties

The directory belongs to the organization: every active workspace of the organization sees the same counterparties, and members with receivables.manage add and change them. What each counterparty owes stays in each workspace; another workspace of the organization sees the company, never its items or receipts. Another organization sees nothing.

A counterparty has a kind (company, agency or OTA), a name, billing details, tax identifiers as text (never parsed), payment terms in calendar days, its usual currency (a default: nothing is converted to it), an optional credit limit (a warning, never a block), whether it allows direct billing (the desk may close folios to its account; off until someone who manages receivables turns it on) and contacts. Contacts are personal data: they stay on the directory row and never enter audit entries or events. An OTA names its Channex channel (ota_name exactly as Channex sends it, such as BookingCom), once per organization. Archive a counterparty to stop billing it; nothing is deleted.

Billing a company folio

1. On a reservation, open a folio other than the first with a company payer (see split folios).
2. Link to counterparty (receivables.manage): the payer becomes the company, with its name and billing details copied as the folio’s snapshot. A company typed by hand stays as typed until someone links it. Renaming the folio keeps the link; giving it another payer drops the link, which needs receivables.manage too and is audited as an unlink.
3. Close and transfer: closing the linked folio while it owes a positive balance moves that balance to an open item of the company and closes the folio settled. The folio shows one Transferred to company account row; it is not a payment, revenue or cash, and the ledger cannot reverse, refund or move it. The item is due after the company’s terms, counted in calendar days from today’s date in the property’s time zone (not a fiscal invoice date). Closing needs receivables.transfer besides folios.split, built in for administrators and the front desk, also when limited to some properties (it then bills at those only), so the desk bills the company and checks the guest out. A folio that owes nothing closes with folios.split alone. Only a counterparty that allows direct billing takes it: any other is refused on the folio’s payer (counterparty.direct_billing_not_allowed), and the desk takes payment instead.
4. Past the company’s credit limit (what it owes this workspace, in the limit’s currency) the close asks for confirmation. A member who reaches every property sees the exposure, the limit and the amount; a desk limited to some properties is told only that the limit is exceeded.

Reopen the folio (receivables.transfer) to take the balance back, even once direct billing is turned off: the transfer is reversed exactly and the item cancelled. While a receipt or a write-off is applied to the item, reopening is refused: release it first under Receivables. A later correction on a transferred folio (a channel’s price amendment) shows as the folio’s balance again and on the item as folio changed after transfer; reopen and close the folio again to bill the new amount.

Receipts, allocations and write-offs

• Record receipt (receivables.manage): money the company paid this workspace, in one currency, by bank transfer, card, cash or other, with a reference and the date received. Cash names the desk’s property and joins its open cash drawer (in the property’s currency; a property that requires an open drawer refuses cash without one). It never posts on a folio.
• Allocate a receipt to one or several open items of the same company and currency, each in part or whole. What is left stays available as credit, visible on the receipt, the aging and the statement.
• Release an allocation to undo it exactly: the item owes it again and the money is available again. Void a receipt recorded by mistake, with a reason, once nothing of it is allocated; voided cash leaves the drawer open then.
• Write off (receivables.write_off) gives up part or all of what an item still owes, with a reason. It is no receipt and no refund. Releasing a write-off makes the item owe it again.

Every write takes a posting key: repeating the same request changes nothing; reusing the key for another request is refused. Every change of an item is audited and emits a receivable.*@1 event (identifiers only).

Expected OTA payouts

When Channex says an OTA collected a booking (payment_collect: ota on the revision), the import opens an expected payout owed by that OTA: the booking total less the OTA commission when Channex supplies it (for Booking.com and Airbnb), otherwise the total, with the commission shown as unknown, never guessed. The import adds the OTA to the directory when it is missing; set its payment terms there (they run from the stay’s departure). A later revision amends the same item; a cancellation’s amounts are followed like any revision’s, never assumed to be zero. A revision whose amounts cannot be true (a negative total or commission, or a commission above the total) is quarantined under Channels as invalid settlement: nothing of it is imported and an existing payout keeps its amount until a correct revision arrives. When the payout arrives, record it as a receipt of the OTA and allocate it; write off a commission that Channex did not supply. GuestCraft does not read Booking.com’s payout reports and does not reconcile bank statements.

A payout the OTA pays by virtual card is recorded by GuestCraft itself: when Stripe confirms the charge of the booking’s virtual card (OTA booking cards), one receipt of the OTA by card, marked From the virtual card charge and naming the provider payment (provider_payment_id), is allocated to the payout as far as it still owes. A difference is never written off for you: what the charge did not cover stays open on the item, what it paid beyond it stays available on the receipt. A refund or a lost dispute of the charge replaces the receipt with one of what the OTA still paid. Such a receipt cannot be voided (receivable.receipt_from_provider): it follows the charge, and only Stripe changes it.

Aging and statements

• Aging shows, per currency, what each counterparty owes by days past due: current until the due date, then 1–30, 31–60, 61–90 and over 90 days, counted on today’s date in each item’s property time zone. Credits (unallocated receipts and overpaid items) are shown apart. CSV.
• Statement of one counterparty over a period: the opening balance, the items opened, amended, cancelled or written off and the receipts by date, and the closing balance, per currency; then the items open now and the credit not yet allocated. It is not a fiscal document. CSV.

Limits

A receipt pays only the items of the workspace that recorded it. Allocation across workspaces of an organization, organization-wide exposure at transfer time, historical aging as of a past date, payout ingestion from OTAs, bank reconciliation, dunning and fiscal invoices or credit notes are not built. The aging, a statement and the credits are read whole, without paging: they suit a workspace’s open items, not years of history in one request.