Connecting Invoicing to an Online Store: Orders, Payments, Invoices, Returns

A connection between a store and an invoicing system is usually built for one case - a successful sale - and breaks on all the others: a cancelled order, a partial payment, a return, or a shipment that never went out. The complete flow covers four events, and only one of them is the sale itself.

The four events to cover

The third row fails in almost every setup: the store knows how to mark an order returned, and the other system does not always hear about it. The result is stock coming back with no document, and a gap in monthly reconciliation.

When is the document created?

This is the first decision, and both options have logic behind them:

• At payment - the most common in a store taking immediate payment. The document is created only when there is money, which prevents documents for abandoned orders.
• At fulfilment - suits a meaningful gap between order and shipment.
• At order - rare in a store, more relevant with business customers on payment terms.

The decision affects stock reconciliation, the sales report, and what the customer receives by email. Settle it with your accountant once, configure it in the system, and do not vary it case by case.

What breaks on a platform upgrade

The most common answer to "why did invoices stop being created" is a store version upgrade. It happens because:

• The plugin was not updated alongside the platform.
• Plugin settings were reset during the upgrade.
• A key or token expired and nobody was alerted.
• A store field changed - an address structure, for example - and the plugin expects the old one.

The way to prevent it is organisational rather than technical: define who checks after every upgrade, and run one small test order. Five minutes after an upgrade saves a month of missing documents.

What to configure at setup

1. When the document is created - as decided.
2. Which document type - per how you work.
3. What happens on cancellation - including cancellation before shipping.
4. What happens on a return - an automatic or manual credit.
5. How the customer is identified - so a new customer is not created per order.
6. What is sent to the customer and when - and on which channel.
7. How shipping is handled - whether shipping cost appears as its own line.

Item five creates a quiet mess: a store that does not recognise a returning customer creates a fresh record on every purchase, and then the customer list inflates and you cannot see who bought how much.

The weekly check

Once a week, two minutes: how many orders were paid in the store, and how many documents were created in the system. If the numbers match, everything works. If not, better to know now than at month end, when you have to work out which order is missing. The same check also catches duplicate orders, which are more common than people think.

What about several sales channels

A business selling through a store, a marketplace and a physical shop has to decide who issues documents for each channel. The rule that works: one system issues, and every channel reports into it. The reverse - each channel issuing its own - produces two or more numbering series, a problem described in invoice numbering and series control. The full picture of unifying channels is in in-store and online clearing in one set of books.

What about shipping costs

Shipping cost is the line that falls between systems: in the store it is part of the order, and in the invoicing system it needs to be an item. If the plugin does not carry it across, the document total does not equal what was charged - a gap that surfaces in reconciliation rather than at setup.

What to check: that shipping appears as its own line rather than being absorbed into the product price; that it also appears on a credit note when goods are returned; and that free shipping appears as a zero-amount line rather than disappearing. The third matters because it explains to the customer why they were not charged, and prevents the question.

How to test this properly at setup

Do not test with one successful sale. Run four small test orders: one paid, one abandoned at payment, one cancelled after payment, and one with a partial return. Those four take twenty minutes and test exactly the four events the table above describes - rather than discovering the last three in month three, when they happen to a real customer.

What stays manual even after connecting

A good connection does not eliminate all the work, and it should not: deciding on an exceptional credit, handling a customer who says they never received something, and monthly reconciliation between store, clearing and bank all stay human. What the connection does remove is the typing and the forgetting - the difference between a business that handles exceptions and one that types every day and handles exceptions in between.

One thing worth checking monthly

Compare three numbers: paid orders in the store, documents in the invoicing system, and deposits in the bank. In a healthy month the first two match exactly and the third differs by fees and refunds. When the first two stop matching, the connection broke somewhere - and finding that in a monthly check beats finding it in a customer complaint.

Sources

• Morning - connections to Wix, WooCommerce and Shopify stores
• iCount - integrations with commerce platforms
• EZcount - clearing for commerce sites and plugins