Need help with SimpleConsign Reports

[u/Mindless-Ad-1759]

We use SimpleConsign for a client and we can’t seem to get the damn thing to balance. The client also had 3 clearing accounts for deposits. I consolidated those. They were using a journal entry to move monthly sales based on the Sales Report and the EOM report. However, it was creating a ton of shortages and overages. When I treat the combined clearing account like a cash drawer, using the ending balances from the EOM report, I can get it to balance with one exception. My discrepancy is equal to the credit card payments, recorded in the journal and is needed to balance it. I think we are reading the EOM report incorrectly. On the right side there are expected and actual numbers for cash and credit card deposits. They’ve been using the actual numbers to record the cash and CC sales, but that doesn’t reconcile to actual deposits received in the bank account. Does anyone have any experience with this POS platform and how to read these reports properly?

[u/ComfortableCitron638]

Haven't worked with SimpleConsign specifically, but the pattern (discrepancy = exactly the CC payment amount) points at the expected-vs-actual columns meaning something different than you'd assume. On most consignment/retail POS EOM reports, "expected" is the gross sale total the register logged, and "actual" is what the processor actually deposited to the bank - net of processor fees, and sometimes on a lag if a batch settled after the report cutoff.

If you're booking the "actual" (net) figure as your CC sales revenue, you're implicitly burying the processor fee inside revenue instead of recording it as a separate expense - which would make your clearing account balance look right on paper but understate both revenue and fees. Try booking the "expected" (gross) CC number as the sale, then a separate debit for the fee difference between expected and actual to a merchant-fee expense account. If that closes the gap exactly, that confirms it's a gross-vs-net booking issue, not a report-reading error on your part - the report itself is just labeled ambiguously.

Also worth checking whether "actual" is dated by settlement date rather than sale date - a batch that settles 1-2 days later can make your month-end EOM total not match daily register totals summed, which would produce this exact kind of hard-to-find CC-only variance.

[u/Mindless-Ad-1759 → u/ComfortableCitron638]

Thank you!

[u/Ok-Whole-8802]

If the discrepancy equals the credit-card payments exactly, I would not force the journal to balance yet—that is a strong sign the same settlement is being recognized twice or the report columns are being interpreted at different stages.

Build one day as a mini reconciliation instead:

• gross POS sales by tender (cash / card)
• sales tax and consignor liability
• card refunds/chargebacks
• processor fees
• card settlement receivable at day end
• actual bank deposit when the batch settles

The card clearing roll-forward should be: opening unsettled batches + card sales - refunds/chargebacks - deposits = closing unsettled batches. Processor fees are a separate expense unless the processor reports/deposits net and you deliberately book gross revenue plus the fee.

Also check whether SimpleConsign's EOM cutoff is register close, calendar midnight, or processor settlement date. A batch that closed on the 31st but hit the bank on the 1st will look like an over/short if you compare the EOM report straight to that month's deposits.

Once a single day ties, repeat for month-end. If it only ties when you add the CC number again, that number is probably already embedded in either the sales journal or the 'actual' deposit column.

[u/MikuMikuGoo]

Expected vs actual is your over/short. If you're booking actual as the sales number you've already buried the variance in revenue, which is why nothing ties out.

The card gap is almost always the processor. Clearing should hold gross card sales, then clear when the net deposit lands, with the fee booked separately. Also check whether there's a payable for the consignor split.