POS Transaction

When a customer taps a card at a register, the authorization, capture, and settlement of payment in exchange for goods or services make up a POS transaction, and every one of them has to land correctly in the general ledger before finance can close the books. A POS transaction is the exchange of payment for goods or services at the point of sale, the physical or digital location where the purchase is completed. For finance teams, the POS transaction is more than an operations event. It is the originating record for cash reconciliation, sales tax collection, and revenue recognition, and it feeds data into the ERP that has to post cleanly or someone corrects it by hand at close.

Authorization, capture, and settlement

A POS transaction moves through three stages that happen quickly but are financially distinct. Authorization is the real-time check by the card network that the cardholder has sufficient funds or credit; it places a hold but does not move money. Capture converts the authorization into a confirmed transaction, typically at the close of the business day in a batch settlement process. Settlement is the actual transfer of funds from the card network to the merchant's bank account, typically occurring one to three business days after capture. For cash accounting purposes, revenue and cash are recognized at capture or settlement depending on policy, not at authorization. If a company recognizes revenue at point of sale for physical goods, the capture event is the trigger. If settlement is delayed, cash on the balance sheet may lag behind recognized revenue by the settlement float period.

POS transaction data vs. ERP posting

POS systems such as Square, Toast, Lightspeed, and Shopify POS generate transaction-level records with tender type, item detail, discount, tax, and timestamp. The ERP needs a summarized journal entry: debit cash or accounts receivable, credit revenue by category, credit sales tax payable by jurisdiction. The integration layer between POS and ERP determines whether that posting is accurate. Common sources of gaps include timing differences between POS close and the ERP posting batch, currency conversion rounding on international transactions, tender type misclassification where gift card redemptions hit revenue rather than liability, and tax jurisdiction mapping errors where the POS collects the right tax but posts it to the wrong tax payable account in the ERP. Each gap needs manual correction at close, and gaps pile up if nobody monitors the integration configuration.

How platforms handle it

A specialty retailer operates 15 locations, each running Lightspeed POS. At the end of each day, the shift manager closes the POS, counts the cash drawer, and compares the count to the system's expected cash position (total cash sales minus any paid-outs). Discrepancies above $5 are flagged and documented. The POS system sends the daily summary to the central accounting team: total sales by tender type, total tax collected by rate, and total voids and refunds. The accounting team reconciles POS tender totals against bank deposits for card settlements received and against the physical cash deposited. Unresolved variances are escalated; variances within a $25 tolerance per location are written off to a cash variance account. The daily summary is then mapped to a journal entry in NetSuite, closing out each day's activity.

Questions to ask

• Does the integration post at the transaction level or at an aggregated daily summary level, and does the chosen granularity support the audit evidence requirements?
• How are tender types mapped? Specifically, how are gift card issuances, redemptions, and split-tender transactions handled in the journal entry?
• What is the latency between POS close and ERP posting, and does that latency create a period-end cutoff risk?
• How are refunds and voids handled: do they reduce the daily sales posting or generate separate reversal entries?
• Is sales tax collected by jurisdiction mapped to the correct tax payable accounts in the ERP, and is there a reconciliation between POS tax collected and tax liability reported?
• What happens to POS transactions if the ERP integration fails? Do they queue for retry, and is there an alert if the queue grows?
• How are end-of-day cash variances tracked, escalated, and resolved across multiple locations?

Where teams get POS transaction accounting wrong

The most common error is treating all POS revenue as immediately realized cash without accounting for the settlement float. Card transactions authorized on the last day of the month may not settle, and so may not reach the bank account, until the following month. If the ERP posts revenue at authorization rather than settlement, cash on the balance sheet is overstated at period-end until settlement arrives. A second persistent problem is gift card liability misclassification. When a customer buys a gift card, the cash received is a liability, not revenue; revenue is recognized when the card is redeemed. POS systems that don't cleanly separate gift card issuance from sales are a common source of audit findings.

Comparing POS systems

POS systems separate on what the payment processing costs and whether you can change processor without replacing the terminals. Once POS Transaction is settled as a requirement, read the Point of Sale Software category guide for how the market splits, then weigh the Square profile against the Toast profile on that requirement rather than on the feature list. No head-to-head comparison is published in this category yet, so the profiles listed in the Point of Sale Software guide are the place to compare. Before you book demos, put your own numbers through the point of sale ROI calculator so the business case is written down before a vendor writes it for you.

Frequently asked questions

Related terms

Inventory Sync and Payment Gateway come up in the same workflow as POS Transaction, and the rest of the POS systems cluster is indexed in the finance operations glossary.