Gas station deposit reconciliation: how to match closeout to bank deposits.

What is deposit reconciliation at a gas station?

Deposit reconciliation is the process of confirming that the cash recorded as deposited from a gas station or c-store actually landed in the operator's bank account at the expected amount, on the expected schedule.

It sits at the end of the cash-handling chain. Drawer reconciliation catches drawer-level errors at shift close. Safe reconciliation catches drop-level errors at end of business day. Deposit reconciliation catches everything that happens between the safe and the bank, the missed deposit, the short deposit, the bag that disappears, the teller error.

The deposit reconciliation workflow

1. Compute expected cash from POS

At shift close, the POS cash-tender row plus prior drawer balance minus cash drops minus cash refunds tells you how much cash should be on hand. Expected cash from the entire business day = sum of per-shift expected cash.

2. Count the drawer and the safe

Drawer counted at shift close (twice, coin and paper separately). Safe contents counted at end of business day. Both numbers go in the audit log with the manager's credentials.

3. Record the manager-prepared deposit

Safe contents at end of day get prepared for the bank run. The manager sums the contents, fills the deposit slip, seals the bag. The slip amount becomes the expected bank credit.

4. Match against the bank credit

The bank receipt lands 1–3 business days later. With Plaid or a direct bank feed, the credit posts automatically into the reconciliation. Without a feed, the operator pulls the statement monthly and matches manually, which is what makes deposit reconciliation the most-skipped step in independent operations.

5. Investigate variance with shift attribution

Any mismatch between expected and actual deposit flags with the shift that prepared the deposit. Most variance resolves as process error within 48 hours of investigation; the residual is the actionable signal.

Worked example: a $-250 deposit variance

Wednesday close. Two shifts ran during the business day. Aggregated expected cash from both shifts = $7,850. Manager counted the safe Wednesday night, prepared a $7,850 deposit, sealed the bag, locked the safe.

Thursday morning the deposit goes to the bank. Friday morning the bank-feed credit lands: $7,600. Variance: $-250.

POS expected cash (sum of both shifts):  $7,850
Counted safe contents Wed night:         $7,850   ✓ matches expected
Deposit slip prepared:                   $7,850   ✓ matches safe
Bank credit Friday:                      $7,600   ✗ variance $-250

Action: investigation triggered Friday morning
- Verify deposit slip image: $7,850 photographed
- Check bank teller receipt: $7,600 acknowledged
- Pull deposit bag tracking: bag delivered intact

Resolution: bank teller miscount.
$250 credit posted Monday after operator escalation.
Audit row updated; attributed to bank, not store.

Common causes of deposit variance

Five patterns cover the majority of deposit variance at independent operators.

1. Deposit miscounted at the safe

Manager prepares the deposit at the end of a long shift and miscounts a strap of bills. The bag is sealed, the slip is wrong, the bank credits the actual amount. Catches by re-count discipline and dual control on deposits over a threshold.

2. Deposit bag short between safe and car

Bag preparation correct; cash removed from the bag after seal. This is the rarest and most serious pattern. Surfaces as a clean chain (slip matches safe matches POS) but bank credits short. Camera review on safe access usually resolves.

3. Deposit posted to the wrong account

Multi-store operators with multiple bank accounts sometimes post a deposit to the wrong store's account. The deposit isn't missing, it's in the wrong place. Surfaces when one store's reconciliation runs short and another runs long by the same amount.

4. Bank teller error

Real and surprisingly common. Teller counts the deposit wrong, the credit posts short, the operator notices, the bank corrects on escalation. The example above is this pattern. Most banks resolve within 5 business days when the deposit slip image is provided.

5. Lag misidentified as variance

Deposit takes longer than expected to post (bank holiday, weekend, the deposit was made after the bank's cutoff time). Not real variance, just lag. Hold expected deposits in an "awaiting" state for 5 business days before flagging as missing.

Deposit reconciliation checklist

• POS expected cash computed per shift, summed per business day.
• Drawer counted twice at shift close; safe counted at end of day.
• Deposit slip prepared and photographed before sealing the bag.
• Deposit bag tracked from safe → car → bank (sign-off at each transition).
• Bank credit reconciled against expected via bank-feed or daily statement.
• Variance flagged with on-deposit-prep manager attribution.
• Lag-aware: 5 business days before flagging as missing deposit.
• Resolution path for bank-teller error documented with deposit slip image.

Plaid vs. manual reconciliation

Two reconciliation patterns. Most independents start with one and move to the other as multi-store complexity scales.

The Plaid pattern doesn't add steps to the manager's workflow, it removes them. The bookkeeper's monthly statement reconciliation drops from a half-day exercise to a 30-minute review of flagged variances.

Multi-store deposit reconciliation

At one store, the deposit-to-account mapping is trivial. At ten stores with ten bank accounts (or one consolidated account with ten deposit slips), the mapping becomes its own data problem.

The cleanest pattern: each store has its own bank account; deposits from store #3 always go into store #3's account. Plaid links each account separately and reconciliation is per-store. Cross- store deposit errors surface immediately because they cause per-store mismatches.

The harder pattern: consolidated bank account with deposit slips tagged by store. Reconciliation has to match deposit slips against bank credits using slip metadata. Workable but more error-prone; most multi-store operators eventually move to per-store accounts.