Can Settlement Wait for a Supplier Confirm?
In one discrepancy row, the decision to close the books often starts with a single pending status.
A status code is not decoration. pending-supplier-confirmation should sit with root cause, evidence references, confirmation deadlines, and approval boundaries, otherwise a difference that is explainable can be written into final books too early.
In channel settlement, variances rarely appear overnight. Room counts, discounts, and tax points may all line up. The last column, though, often remains marked pending, like a note waiting on the last signature. That note looks narrow: supplier confirm not yet received. In practice it decides close eligibility, cash timing, and when reconciliation messages can be emitted.
Most delays on this status are not system slowness. They are missing object shape. If a variance row only stores an amount and voucher number, the next move becomes “the books look good, so close them,” and later the supplier says the version reference was old. The conflict is not about blame. It is about a pending state that does not connect to evidence version, ownership, and escalation path.
The fix is not better reminders. It is making the status a reviewable object. A variance row should include diff_id, dispute_reason, evidence_ref, supply_confirmer, expire_at, and fallback_action. Then finance can decide whether to trigger a pre-close warning, when a hard close is allowed, and who can escalate when supplier confirmation expires.
HotelByte should keep distribution and settlement coupled, not entangled. Orders can keep serving; finance can keep risk controls. This works when pending means “boundaried waiting,” not “ignored waiting.” A clearly shaped status object keeps both supplier and finance looking at the same line and the same timeline.