Why this matters
An online store records a sale the moment a customer pays. Accounting needs that sale split into revenue, sales tax, shipping income, discounts, payment fees and sometimes inventory cost. If someone retypes orders into accounting at the end of the week, the numbers arrive late and the split gets flattened. Reports then disagree with the store, and nobody can trace a refund back to the original order.
The work in how to connect online store to accounting software is mostly mapping and reconciliation, not clicking a Connect button. Stores produce high volumes of small transactions. Payment processors settle in batches. Refunds arrive days later. A good connection turns that stream into journal entries your accountant can audit, with a store order ID on every line.
The payoff is a single trail from order to bank deposit. You can close the month without comparing three exports by hand, and you can answer a customer question about a refund without opening four systems.
Before you start
Decide the level of detail accounting needs. Most stores post a daily sales summary by channel, with one journal entry for sales, tax, discounts, shipping, fees and the net payout. That keeps the ledger readable. If you sell on net terms, drop ship, or need order level margin, post one invoice per order instead. Write the choice down before you configure anything.
Agree the accounts with whoever owns the books. You need an account for sales, sales discounts, shipping income, sales tax payable, payment processing fees, refunds, inventory asset and cost of goods sold. For stores with gift cards, add a gift card liability account. Get the tax codes right too, since tax collected is not revenue.
Export a sample of orders, refunds and payouts from the store and the payment processor. Include an order with a discount, a partial refund, a tax exempt customer, a guest checkout and a different currency if you use one. These samples become your test cases. Note the stable IDs: order ID, refund ID, transaction ID and SKU. Product names change; IDs should not.
Set a cutover date and stop manual sales entries on that date. Pick a short backfill window, such as the current month plus the prior month, rather than rebuilding years of history. Clean product SKUs first. Every item you sell needs a unique SKU that matches the accounting item or product record.
How to do it
Choose a sync pattern before you pick a tool. A native connector from the store or accounting software can handle a daily summary, but check how it treats refunds, fees and multi-currency. Middleware gives more control over field mapping and retries. Either way, the accounting side needs a clearing account for money in transit so a payout does not count as new revenue.
Build the connection in a test store or sandbox copy first. Post a handful of orders, refunds and payouts, then inspect every journal line. Do not switch on the live sync until the test batch reconciles to the penny. Keep one person responsible for the connection and one backup who knows where the mapping document lives.
- Map accounts and tax codes. List every store amount that hits the ledger: item sales, discounts, shipping charged, shipping tax, sales tax, refunds, processor fees and gift cards. Assign each one a general ledger account and a tax code, by store view and currency. Put the map in a shared document that finance can edit.
- Clean product and customer records. Give every sellable item a unique SKU and match it to the accounting item or product code. Set tax category and cost on the product record. Keep guest orders as guest orders; do not merge customers by name or email unless finance has a rule for it.
- Pick order level or daily summary posting. Use daily summary posting for card heavy retail stores and order level invoices for net terms or detailed margin reporting. Write down which statuses trigger a post, such as paid, fulfilled or captured. Never post the same order twice when status changes.
- Connect in a sandbox and set permissions. Authorize the connector in a test store or sandbox company file. Give it the narrowest scope that still reads orders, refunds, payouts and products. Avoid using a shared admin login; create a named integration user so the audit trail means something.
- Configure field mapping and journal memos. Map order ID, refund ID, currency, tax code and SKU to the matching accounting fields. Put the store order number and payout ID in the journal memo. Map discounts and shipping to their own lines instead of rolling them into sales.
- Set up the clearing account and payout match. Post gross sales to a payment clearing account, post processor fees as an expense, and let the bank payout clear the clearing balance. Refunds reduce the clearing account and reverse the original revenue and tax. Check the clearing balance after each payout.
- Backfill a short window and go live. Import the current period and one prior period, then reconcile those entries before the cutover date. Freeze manual sales entries from the cutover forward. Turn on the live sync and watch the first few payouts closely.
How to check it worked
Reconcile the first full period from the store outward. Compare the store sales report to accounting revenue by day: gross sales, discounts, shipping, tax, refunds and net. The totals should match after you account for timing. Then compare the payment processor payout total to the clearing account and the bank deposit.
Test the awkward cases on purpose. Run a partial refund, a full refund, a discount code, a tax exempt order, a guest checkout and a gift card if you use them. Each should produce the right journal lines and no duplicate. Look for failed jobs or rejected records in the connector log, not just in the store.
Check inventory and cost of goods sold if you track stock in accounting. A sale should reduce inventory and record cost at the same time, using the cost on the product record. If you keep inventory only in the store, say so in the mapping document so nobody expects the ledger to carry stock.
Review the audit trail. Every journal entry should show the source, the order or payout ID and the date. A reviewer should be able to follow one order from store checkout to bank deposit without opening a spreadsheet.
Mistakes to avoid
Posting both the order total and the payout as income is the classic error. The order creates revenue and a receivable or clearing balance; the payout moves cash and clears that balance. If both hit sales, revenue doubles. Use a clearing account and reconcile it every time.
Do not lump discounts, shipping and tax into one sales line. That hides tax liability and makes margin reports wrong. Do not use product names as matching keys, and do not change a SKU after it has posted without a mapping update.
Do not let the sync run without an owner. A connector that fails silently is worse than a manual process because people trust it. Set alerts for failed jobs, rejected records and clearing balances that do not clear. Keep a dead letter queue or an error report that someone reviews.
If your team is still rekeying store data into finance tools, Cloudverg's Systems integration build at $12,500/month is one option among others. It covers an integration map, live integrations with retries, field mapping, alerting and a handover session. A native connector or a middleware subscription can also work for a simpler store. Match the choice to how much control you need over refunds, fees and multi-currency.
Frequently asked questions
Should I sync each online order to accounting or post a daily summary?
For card heavy stores, a daily summary by channel keeps the ledger clean and still ties to payouts. Use order level invoices for net terms, margin by order, or serial numbers. You can mix the two if one channel needs different detail.
How do I handle payment processor fees and payouts in accounting?
Post the gross sale to a payment clearing account, record the processor fee as an expense, and let the bank payout clear the balance. The clearing account should return to zero after each settlement. If the payout does not match, fix the missing refund or fee first.
What happens to refunds and partial refunds in the sync?
A refund should reverse the original revenue, tax and any shipping charge, and it should reference the original order ID. Partial refunds need line level mapping so a returned item goes back to inventory. Watch the fee treatment, because some processors do not return the original fee.