Store credit, gift cards and the liability you may be counting twice

Theoretical Enterprises · October 24, 2026 · 6 min read

Store credit and gift cards feel like marketing tools, and they are usually set up by whoever runs the store. In the books they are something else: money already taken, or value already promised, for goods not yet handed over. When the store holds those balances in one place, the ledger sits in another, and nothing connects the two, the number on the balance sheet is a guess. Sometimes it is counted twice. Sometimes it is not there at all.

Is store credit a liability?

Yes. A store credit balance is an amount the business owes a customer, payable in goods. It belongs on the balance sheet as a liability until it is spent, and it comes off when it is redeemed and the goods go out.

How the balance got there matters, because each route is booked differently.

Gift card sold. Cash comes in and the liability goes up by the same amount. There is no revenue yet; revenue is recorded when the card is spent on goods.
Refund issued as store credit. The original sale is reversed, along with the sales tax charged on it, and what the business owes moves from the customer's card to a credit balance.
Credit given as a goodwill gesture or a promotion. No cash came in, so how it is booked is a policy decision: some businesses record the cost when the credit is issued, others when it is used. Decide once, with your accountant, and apply it every time.
Balances nobody uses. Old, unspent balances cannot simply be written off as income. Some states treat them as unclaimed property with their own reporting rules, so ask before clearing them.

How can store credit end up counted twice?

Most stores add store credit with a plugin, and a store that has grown for a while sometimes has two: one that came with a coupon or loyalty tool, and one added later for refunds or gift cards. Each keeps its own list of balances. Neither knows the other exists.

That is how a balance ends up in the wrong place. A credit issued in one tool and spent through the other leaves the first balance open forever. A bookkeeper who adds both reports together counts some customers twice. One who uses only one report misses the other entirely. And if the ledger only ever sees orders, net of whatever credit was applied, the liability is never recorded at all: the books show less revenue on the day the credit is spent, and no sign of the debt before that.

Gift cards set up as an ordinary product cause a related problem. The store records a sale the day the card is bought, may charge sales tax on the card itself, and then records the later purchase as a discount. Revenue arrives early and the liability never appears. Sales tax is generally due on the goods when the card is spent, not on the card when it is sold; check the rule in each state where you collect.

What should each store transaction post to the ledger?

The fix is to treat every store event as a journal entry with the order number on it, posted by the integration rather than typed in. Decide first whether revenue is recorded when an order is paid or when it ships, and use that date everywhere. After that, the list for a typical store is short.

Order paid: revenue by product category, shipping income, sales tax owed to each jurisdiction, and the amount paid into a payment clearing account. Discounts are recorded as discounts, not netted away.
Store credit or a gift card applied at checkout: the liability goes down by the amount used, in place of cash.
Refund to the card: the sale and its tax reversed, and the money out of the clearing account.
Refund to store credit: the sale and its tax reversed, and the store credit liability up by the same amount.
Gift card sold: cash into clearing, the liability up, no revenue.
Payout from the payment processor: the deposit into the bank, the processing fee as an expense, and the clearing account down by the full amount the payout covers.

Why the processor deposit never matches the day's sales

Owners often try to match each bank deposit to the store's sales report, and give up. The two are not meant to match. The processor batches several days of payments, may hold some back, takes its fees out and deposits what is left. Refunds and chargebacks come out of later deposits.

A clearing account solves this. Every payment goes in at its full amount when it is taken, every payout comes out at the full amount it covers when it lands, and the fees are recorded as their own expense instead of being buried in a smaller deposit. At any moment, what is left in the account is money the processor is holding for you, and it can be checked against the processor's own report. When the two differ, something was missed: a refund, a chargeback, a fee.

How should sales tax by jurisdiction reach the books?

A store that sells across state lines may collect tax for many jurisdictions, each with its own rate and its own return. A tax service usually calculates it at checkout, and that part tends to work. The weak point is what happens next: the tax often reaches the ledger as one lump inside a deposit, if it arrives separately at all.

Tax collected is not income. It is owed to the jurisdiction that charged it. It should post as a liability by jurisdiction on every order, come off in the same jurisdiction when an order is refunded or cancelled, and clear when the return is filed and paid. Exempt buyers, such as resellers and wholesale accounts, need their exemption certificates on file and their orders marked, so the tax service and the ledger agree on why no tax was charged. Then the amount on each return is simply the balance in the ledger, not a separate calculation.

What does tying out at month-end mean for an online store?

It means every balance in the ledger can be proved against the system that produced it, quickly, every month. For a store, five checks cover most of it.

Store credit and gift cards: the liability in the ledger equals the total of open balances in the store, from one report, in one tool.
Payment clearing: the balance equals what the processor says it is holding, with every difference explained.
Sales tax: the liability for each jurisdiction equals the tax service's report for the period.
Revenue: sales in the ledger equal the store's sales report, net of refunds, using the same recognition date.
Exceptions: a list of orders with no ledger entry, and entries with no order. When every entry carries its order number, that list is short and each line says what to fix.

Where to start

None of this needs a new store. It usually starts with two decisions and one integration: choose one place for customer balances and move the rest into it, agree with your accountant how each kind of credit is booked, then have orders, refunds, payouts and tax post to the ledger as entries that carry the order number. The first month-end after that is the test. The five checks above should be a review, not an investigation.