Dealer Casebook: Paper and System Records Disagree

A network, terminal, interface, or casino system was unavailable during a live transaction. The property used an authorised paper or manual fallback.

Later, the system returns. A restored entry appears, but it does not match the paper record. The amount may differ. The table may differ. The system may show a transaction that staff thought was only on paper, or the manual form may show something the system does not.

The dangerous shortcut is to decide that one medium must be right simply because it looks more official.

Neither medium automatically wins. Preserve both records, reconstruct the underlying event, and do not create a duplicate posting or duplicate value movement while the mismatch is unresolved.

Start with the event, not the technology

Ask what physically happened at the table.

Did chips arrive? Did chips leave? Did cash change custody? Was a marker-related value movement completed? Who counted or received it? What was the rack state before and after?

The system and paper are ways of recording that event. The first task is to understand the event itself.

Do not post again merely because one record is missing

If the paper shows a 10,000 fill and the restored system does not, do not automatically create a new system transaction from the table unless the authorised recovery process confirms that is required.

The original event may already be queued, delayed, duplicated elsewhere, or represented under another identifier.

A second posting can create a new discrepancy instead of solving the old one.

Do not move value again to match the restored screen

Similarly, do not add chips to the rack or remove them because the screen shows a state different from the paper.

Physical value should move only under a clear authorised transaction, not as an improvised attempt to make two records agree.

If the current rack is uncertain, preserve it for review.

Compare the fields you are authorised to see

Useful points may include:

• table number;
• transaction type;
• amount and denominations;
• time recorded manually;
• system time or visible transaction identifier;
• preparer, receiver, witness, or authorisation fields;
• whether the manual record says pending, completed, void, or replacement;
• whether a later system entry appears to refer to the same event.

Do not access technical logs or restricted system areas outside your role.

Do not assume electronic means correct

Systems can be authoritative within a property’s process, but a restored screen can still require reconciliation with what happened during an outage.

A delayed entry, duplicate recovery, incorrect manual transfer, or user error may all be possible. The dealer should not diagnose the technical cause.

Report the mismatch and preserve the evidence.

Do not assume paper means correct

Manual fallback records can also contain mistakes.

Someone may have written the wrong amount, copied the wrong table number, or misunderstood whether the transaction completed before the outage.

The existence of handwriting does not automatically make the paper record superior to the system record.

Protect the rack and open transaction state

If the mismatch affects table bankroll or custody, keep new movements controlled.

The floor may allow play to continue while another authorised person reconciles the transaction. If so, make sure later fills, credits, colour-ups, cash exchanges, or rack changes do not become confused with the open item.

For related state-preservation thinking, see Power or Network Outage at a Live Table if present in your property workflow; if that exact route is not part of the current site, the same principle is covered by Rack and Float Discrepancies.

Keep recovery internals out of table speculation

Do not tell players or other staff that “the server duplicated it,” “the database lost it,” or “the network replayed the transaction” unless the authorised technical team has established that fact and it is appropriate to share.

The dealer normally needs only the operational statement:

“The manual record and restored system record do not match, and the transaction is being reconciled.”

If both records show the same amount but different details

A mismatch is still material if the table, transaction type, player identifier, time, or another controlled field differs.

Do not focus only on the money total. Correct amount plus wrong identity can still create a poor record trail.

Identify the exact field conflict for the authorised reviewer.

If the rack balances

A balanced rack is useful evidence, not final proof that the records are correct.

The issue may be duplication, timing, misclassification, or a record assigned to the wrong table. A later reconciliation can still fail even if the current physical amount looks right.

Do not discard the paper simply because the rack balance reassures you.

If a manual record was already marked complete

Do not change its status privately when the system returns.

If the authorised recovery process requires a cross-reference, replacement, void, or system reconciliation notation, follow that process. Preserve what the paper originally showed.

A late system restoration should not silently rewrite the history of the outage period.

If a player is affected

Avoid promising a credit, payment, reversal, or correction before the authorised review.

A useful statement is:

“There is a mismatch between the outage record and the restored system entry. The floor is confirming the completed transaction before any additional movement.”

That is transparent without claiming a technical cause or result.

Handover both states

If relief or shift change occurs, explain:

• the manual record identifier and status;
• the visible system entry and how it differs;
• what value movement you personally observed;
• whether the rack or cash state is settled;
• who is reconciling the mismatch;
• whether any new posting or movement has been authorised.

Do not hand over only the paper or only the screen.

Document the operational sequence

A factual note might say:

“During the outage at approximately 22:50, a manual 8,000 fill record was completed for Table 11 and the chips were placed in the rack. After service returned, the system displayed a 10,000 fill entry for the same table and approximate period. I did not enter a second fill or move additional chips. The paper record and system entry were referred to the floor for reconciliation.”

That is useful without exposing recovery internals.

Tie the review to one transaction reference where possible

When the property provides a visible transaction number, manual-form number, time window, or other authorised reference, use it consistently in the handover. The aim is to stop two teams from treating the paper event and restored system event as separate simply because they carry different timestamps or formats. Do not invent technical identifiers or enter restricted recovery screens; use only the references available to your role.

Do not reopen settled value without an authorised ruling

If the player has already received chips, cash, a marker outcome, or another completed value movement, the later record mismatch does not by itself authorise the dealer to reverse or repeat that value. Preserve the current state and let the authorised reconciliation determine whether any corrective transaction is required. This protects the player and the casino from a second movement created only by uncertainty.

Reconcile the event before reconciling the systems

An outage can create two versions of the same transaction story. The dealer should not resolve that conflict by trusting a medium blindly, posting twice, or moving value again.

Neither medium automatically wins. Preserve both records, protect the physical state, and reconcile the underlying event through the authorised recovery process without duplicate posting or duplicate value movement.