Net 30 Orders Should Land in Your Accounting System as Open Invoices, Not Paid Receipts

A buyer places a wholesale order on net 30. The store takes it, the warehouse ships it, and the order appears in your accounting system a minute later. Everything looks connected.

Now open your accounts receivable report. The order is not on it.

It is sitting in the ledger as a paid sales receipt, for money nobody has sent you. Nobody will chase it, because the books say it is settled. Six weeks later a transfer arrives covering four orders, and somebody spends an afternoon working out what it was for.

The short answer: An order on payment terms should post to your accounting system as an open invoice with a due date, not as a paid sales receipt. Receipts record money you already hold. Terms orders are money you are owed, so they belong in accounts receivable until the transfer arrives and gets applied against that invoice.

Net 30 is a payment term where the buyer receives the goods now and pays the full invoice within 30 days of the invoice date. That one fact should change what your systems write down.

Why does your connector post every wholesale order as paid?

This is not a bug. It is a default built for a different customer.

Most store-to-accounting connectors were designed for consumer retail, where the card is charged before the order is confirmed. Order and payment happen in the same second, so the connector writes one document for both.

QuickBooks documents that an invoice "informs your customers of what they owe you", while a sales receipt "records goods or services paid for immediately at the time of purchase". A receipt states that you hold the cash. For a terms order, that is false.

The store usually knows better than the ledger. Shopify's B2B documentation shows the platform modelling terms properly: the available terms run from net 7 to net 90, and "all terms start from the day the order is placed". The same page adds that "payments aren't automatically captured when the payment terms expire", and that the order then shows as Overdue to the buyer.

So the due date exists. The unpaid status exists. They stop at the boundary, because the connector only knows how to write "paid". Same problem as an integration that fails without telling anyone: the damage comes from the silence.

What breaks when a net 30 order lands as a receipt?

Four things, in the order you notice them.

Nobody chases the money. Collections work off the aging report, and accounts receivable is money owed for goods already supplied. An order that never became an invoice is not on that report, so it is never overdue.

The cash forecast is wrong both ways. Today it overstates cash you hold. Next month it understates what is due in.

Reconciliation breaks when the transfer lands. A buyer pays three invoices with one transfer. If those invoices do not exist, the payment sits unapplied or gets coded straight to sales, and the revenue is in the books twice.

Your credit picture disappears. You cannot see that an account is at its limit if half its open orders were recorded as settled.

Both flows below are correct, for different order types.

	Prepaid order (card paid at checkout)	Terms order (net 30, 60 or 90)
When cash arrives	Before the goods ship	Weeks after the goods ship
Correct document	Sales receipt, or invoice marked paid	Open invoice with an issue date and a due date
Where it appears	Sales, plus a clearing account for the payout	Sales, plus accounts receivable
Reference the buyer needs	Order number	Purchase order (PO) number
What the bank line reconciles against	The platform payout batch	One or more specific open invoices

How do you check your own setup in ten minutes?

Do not read the settings page. Watch what your connector writes.

1. Create a test company account with net 30 terms, or use a quiet real one.
2. Place a small test order on those terms, for one cheap item.
3. After the sync, find the document it created in the accounting system.
4. Ask three questions of it. Does it have a due date? Is the outstanding balance greater than zero? Does it appear on the aging report?
5. Check which customer record it sits against, and whether the PO number made it across.

Any no means you have found it. Void the test document afterwards so it does not pollute the month.

What should a terms order map to in your ledger?

The fix is a mapping job, not a new system. This is ordinary software integration work between the store and the ledger you run.

• The company, not the buyer. Three people at the same dealer must post to one customer record, or the aging report fragments and credit limits mean nothing.
• The PO number. Most B2B buyers will not pay an invoice that does not quote it. Put it in the invoice reference field, not a note nobody prints.
• Issue date and due date. Shopify's developer documentation covers fixed, net and event-based terms plus percentage deposits, and net terms there run from the order date. Decide which date your ledger uses, then hold it.
• Tax treatment. Official EU guidance is that you do not charge VAT on goods sent to a business in another EU country if the customer has a valid EU VAT number, with services handled by the customer under the reverse charge. Map tax per line from the order.
• Line detail. Stock keeping units (SKUs), quantities, the price actually charged, shipping and discounts, each to the right ledger account. The invoice must carry that account's contract price, not the list price.
• Part payments and credit notes. A deposit reduces the balance on one invoice. A short shipment or return gets a credit note against the original, keeping the audit trail.
• Idempotency. Stripe documents the pattern worth copying: it saves the result of the first request for a given idempotency key and returns it for later requests with the same key. A retry must update the existing invoice, never raise a second. Duplicate invoices come from the same place as duplicate orders in an integration.

If your integration listens to webhooks, know how long the platform keeps trying. Shopify documents that it retries failed webhook calls up to eight times in a four-hour period, then removes the subscription. An order that arrives while your endpoint is down does not queue forever. It never becomes an invoice, and nothing tells you.

What does a missing invoice actually cost?

The numbers below are illustrative. Redo them with yours.

Say you ship 40 orders a month on terms, at an average order value (AOV) of €1,800. One in ten posts as a paid receipt, through a channel the mapping does not cover.

• 40 × 10% = 4 orders a month
• 4 × €1,800 = €7,200 a month that never enters accounts receivable
• Over six months, €43,200 of invoices that were never raised

Most of that money arrives eventually, because buyers pay against their own purchase orders. But it arrives late and unasked for. Say half get caught at reconciliation, at 45 minutes each: 24 × 45 minutes is 18 hours over six months, or about €630 of rework at €35 an hour.

The other half is the real problem. Those are invoices nobody raised, on accounts that have no idea they owe you. If one stops trading, that is not a late payment. It is a write-off you never provisioned for.

Fixing the mapping is not free either, and someone still handles the exceptions. Price that before you commit, the same way you would any other automation decision.

Where does a person have to stay in the loop?

Automating the document does not mean automating the judgment. Keep a human decision on:

• Credit limits. An order that takes an account past its limit should stop and wait.
• Terms changes. Moving an account from prepaid to net 30 is a commercial decision.
• Disputes. When a buyer short-pays for a damaged pallet, the credit note is a negotiation first.
• Write-offs and payment plans. Never automatic.

The issuing, numbering, due dates, payment application and the reminder at day 25 are mechanical. They belong to the machine.

When is this not worth automating?

• You ship a handful of terms orders a month. Four invoices by hand is not a project.
• Your enterprise resource planning (ERP) system already owns the order. Fix the ERP flow instead.
• Billing is bespoke per order. Milestone billing and consignment need a person, not a rule.
• Nobody reads the aging report. Raising more invoices changes nothing.

What should you measure before and after?

Write these down before you touch anything:

• Terms orders shipped per month, and how many appear on the aging report within 24 hours
• Days sales outstanding (DSO), or your simplest version of it
• Unapplied payments sitting in the ledger at month end
• Hours spent on month-end reconciliation
• Credit notes raised only to correct a wrongly posted document

Check again after two billing cycles. The first number matters most: the share of terms orders that become open invoices untouched.

How do you fix this in one week?

1. Place one test order on terms and find the document it created.
2. Check it for a due date, an outstanding balance and a place on the aging report.
3. List the missing fields: company, PO number, due date, tax.
4. Map them between store and ledger, with the order number as the unique key.
5. Re-run the test, then reconcile one real buyer payment end to end.

That is the Find, Prioritize, Automate approach on one document. Then take the next handoff from the wider B2B automation audit.

FAQ

Why does my store-to-accounting connector mark wholesale orders as paid?

Because most connectors were built for consumer retail, where the card is charged at checkout and the order and the payment are the same event. They write one document that records both. Wholesale orders on payment terms separate those events by weeks, so the default records money you have not received.

Should a net 30 order create an invoice or a sales receipt?

An invoice. A sales receipt says the money is already in hand, which is only true for a prepaid order. A net 30 order should create an open invoice with an issue date, a due date and an outstanding balance, so it stays on the accounts receivable aging report until the payment is applied.

Which customer record should a wholesale invoice sit against?

The company, not the individual who placed the order. Several buyers at the same dealer need to roll up into one customer record. Otherwise the aging report splits across duplicates, credit limits cannot be enforced, and one payment covering several orders has no clean place to land.

How should part payments on a wholesale invoice be handled?

Apply the payment against the existing invoice so the outstanding balance drops. Do not create a second document for the remainder. The invoice keeps its original due date and stays on the aging report until it is fully settled.

What happens when a buyer returns part of a terms order?

Raise a credit note against the original invoice rather than editing or deleting it. The credit note reduces the open balance, keeps the audit trail intact, and gives the buyer a document they can match to their own purchase order.

Can I fix orders that already posted as receipts?

Yes, but do it deliberately. Pull the list of terms orders that posted as paid, agree the correction with whoever owns the books, and void or reverse each one before raising the correct invoice with its original date. Fix the mapping first, or you will repeat the cleanup next month.

Sources

• Shopify Help Center: Setting up payment terms in B2B for net terms, the order-date start, deposits and manual capture.
• Shopify developer docs: Set payment terms for fixed, net and event-based terms.
• QuickBooks: Invoices, sales receipts, bills and statements for both document definitions.
• Xero: What is accounts receivable? for the accounts receivable definition.
• Stripe API reference: Idempotent requests for documented idempotency-key behaviour.
• Your Europe: Cross-border VAT rates in Europe for EU B2B VAT and the reverse charge.
• Shopify developer docs: Troubleshoot webhooks for the webhook retry window.