An order and warehouse management layer should hand the ledger three things: sales summarized by channel and period, the cost of fulfilling those sales, and inventory movements that change what the inventory is worth. It should keep everything else. Order status changes, allocation events, pick lists, listing syncs, and quantity pings are operations data. They belong in the operations system, where someone can look them up, and nowhere near the general ledger, where they would bury the numbers an accountant needs under thousands of lines nobody will read.
Goflow is multichannel ecommerce software. Per goflow.com, it manages orders, inventory, shipping, fulfillment, purchasing, and receiving across sales channels, and lists integrations with more than 250 marketplaces and channels. It sits between the marketplaces and your books. ConnectBooks connects Goflow data to QuickBooks or Xero, which makes the question of what crosses the line a practical one rather than a design exercise.
Sales, summarized. The ledger needs revenue by channel for the period, with refunds and marketplace fees separated out. It does not need 14,000 individual orders as 14,000 invoices. The order-level detail is the operations system's job, and a good handoff lets the accountant trace a summary line back to the orders behind it without storing those orders in QuickBooks.
Fulfillment cost. Labels, 3PL charges, packaging. Whichever line your policy puts them on, they have to arrive in the books matched to the period of the sale, not the period the carrier invoiced.
Inventory movements that change value. Receipts against purchase orders add value. COGS relief at sale removes it. Write-offs, damage, and disposals remove it. Transfers between warehouses may change it, which is the case worked through below.
Every status change on an order. An order that goes from received to allocated to picked to packed to shipped has produced five events and one accounting fact: it shipped, on this date, at this cost. Send the fact.
Inventory quantity, in real time. The operations layer updates on-hand counts every time an order allocates or ships. The ledger does not want a running quantity. It wants the value of inventory at period end, and the movements that got it there.
Listing and catalog changes. A price change on a listing is not a transaction until someone buys at the new price.
The place multichannel sellers get hurt is inventory, because both systems have an opinion about it and they are opinions about different things.
The operations layer owns quantity. How many units of SKU X are in Warehouse A right now, how many are allocated to open orders, how many are in transit to Warehouse B. It has to be right to the unit and current to the minute, because it decides whether the next order can ship.
The ledger owns value. What those units cost, layer by layer under FIFO, and therefore what COGS will be when they sell and what the balance sheet carries at month end. It has to be right to the dollar and current to the period.
The trap is letting both systems compute value. The operations layer usually carries a unit cost field, often a single average or the last PO price. If that cost feeds the ledger, and the ledger also computes FIFO from receipts, the two will drift. Not by much in a quiet month. By a lot after a supplier price increase, because the average creeps and FIFO jumps when the old layer runs out. Pick one system to compute value and let the other one hold quantity. Inventory tracking by warehouse in ConnectBooks carries FIFO layers and landed cost so that the value side lives in the same place as the books it feeds.
Illustrative numbers. Take a seller with 500 units of SKU X in Warehouse A, held in two FIFO layers.
The seller moves 250 units to Warehouse B, closer to a 3PL that serves the West Coast. Freight for the transfer is $375.
In the operations layer this is a quantity event. Warehouse A drops to 250. The 250 in motion show as in transit until Warehouse B receives them, then B shows 250. No sale, no customer, no revenue.
In the ledger it is a value event, and there are two defensible treatments.
Capitalize the freight. The $375 is a cost of getting inventory to the location it will sell from, so it attaches to the transferred units. FIFO takes the transfer from the oldest layer: 250 units at $8.00 is $2,000, plus $375 freight, or $2,375. That is $9.50 per unit at Warehouse B. Warehouse A keeps 50 units at $8.00 and 200 at $9.50, or $2,300. Total inventory value is now $4,675. Cash went down $375, inventory went up $375, and the P&L did not move.
Expense the freight. Inventory stays at $4,300. Freight expense of $375 hits October's P&L. Profit is $375 lower this month with nothing sold.
Now Warehouse B sells 100 units in November. Under the capitalized treatment COGS is 100 times $9.50, or $950. Under the expensed treatment it is 100 times $8.00, or $800. The $150 difference is the freight, showing up in November instead of October. Over the life of the 250 units the two methods produce the same total profit. In any single month they do not, and a seller comparing October to November on the expensed method sees a margin swing that is an artifact of the freight decision.
Two more things this example shows. First, the transfer has to carry its cost layer, not the SKU's average. If the operations layer reports the transferred units at an average cost of $8.60 and the ledger books them that way, Warehouse A is left holding layers that no longer add up. Second, in-transit inventory is still your inventory. A transfer that left on October 30 and arrived November 2 has to appear on the October 31 balance sheet, which is why ConnectBooks tracks transfers as in transit until received. The longer version of this problem, including what happens when the receiving count is short, is in warehouse transfers and inventory value.
Once a month, compare the operations layer's on-hand quantity by warehouse to the ledger's implied quantity, which is receipts minus COGS units minus write-offs. They will not match. The difference is the list of things one system knows and the other does not: damaged units scrapped on the floor, a free replacement shipped with no sale, a receipt counted short, a return restocked without a credit memo. Each one becomes an entry.
Then value the operations quantity at FIFO and compare it to the ledger's inventory balance. The gap after the quantity reconciliation should be small and explainable. If it is not, the two systems are both computing cost, and one of them has to stop.
ConnectBooks reconciles marketplace settlements into QuickBooks or Xero and carries FIFO inventory value, landed cost, and in-transit transfers on the accounting side. Goflow data connects to it as one more source. The operations layer keeps the orders. The books keep the value. Nobody has to read 14,000 status changes to close the month.
Running an e-commerce business comes with plenty of challenges, but ConnectBooks is here to make your life easier. With real-time insights, seamless integrations, and detailed tracking of your profitability and inventory, you can stay ahead of the game. Whether you’re selling on Amazon, Shopify, Walmart, TikTok or eBay, ConnectBooks helps you manage your finances with 100% accuracy and confidence, so you can focus on growing your business.
Ready to level up? Start making smarter, data-driven decisions every step of the way. Try ConnectBooks Free Today or Schedule a Demo
