When does an online order become an AFAS sales order or invoice?

Have accounting approve in advance when an online order is technically submitted as an AFAS sales order or a direct invoice. Open fulfilment often points to a sales order, while a direct invoice fits only an explicitly defined business event. Never make the choice automatically from one payment status: payment, delivery and invoicing are different events.

Start with the business process, not the connector

A paid order may still need picking, a partial backorder, delivery or cancellation. A collection order may be ready while the customer arrives later. For digital or immediately fulfilled products, invoicing may be appropriate almost at once. The correct AFAS destination type therefore depends on the revenue event, stock process, logistics and accounting agreements.

First describe which source event proves an order is commercially accepted and which event permits delivery or invoicing. Configure the flow only after that. The integration can technically submit either an order or an invoice, but technology should not invent missing financial policy. Always have the responsible accounting team assess the setup; this is not accounting or tax advice.

A fulfilment matrix as a decision document

Order type Next physical step Possible AFAS route Required evidence
Parcel for shipping Pick, pack and hand over Sales order Valid order and delivery details
Own delivery service Capacity and route Sales order Feasible delivery date and address
Collection Reserve and mark ready According to the agreed process Location, time and collection evidence
Immediately completed delivery No open fulfilment Possibly a direct invoice Demonstrable invoicing event

Replace “possible” in your own matrix with an approved choice and exceptions. Also document returns, partial deliveries, zero-value backorders and changes after acceptance. The basis for the technical mapping is described in Connect WooCommerce to AFAS.

Fictional example: paid, but not yet delivered

Fictional example: kitchen store Vormvast receives a paid order with four items, one of which becomes available later. The configuration creates an AFAS sales order with the validated lines. The parcel step waits for the agreed fulfilment moment, and the backorder receives separate operational follow-up. Payment alone does not trigger a direct invoice that makes later changes unnecessarily complicated.

A second fictional order concerns an immediately delivered digital instruction for which accounting uses a pre-approved direct-invoice route. The workflow selects that route from the explicit product and fulfilment type, not because both orders are “paid”. The audit trail records which rule determined the choice. Accounting can then explain afterwards why two paid orders were processed differently.

Questions before activation

  • Which fact makes the order sufficiently final for AFAS?
  • Under your own policy, is delivery, payment or acceptance the invoicing event?
  • How are partial deliveries, discounts, shipping costs and backorders represented?
  • Which external identity prevents a second order or invoice on retry?
  • Which step may then start parcel processing or a route?
  • How does an employee see an exception, and who may resolve it?

In Connect sales-order and direct-invoice flows can be configured as separate options. Desk then shows which route was chosen for an order and where a dependency remains open. Test the matrix with real order types and fictional personal details before production.

Include amounts and later changes in that test too. Place an order with a discount, shipping costs and several VAT rates; then change one line before fulfilment and cancel a second test order. For each route, check how corrections and source identity are processed. A choice that looks right in the standard scenario can create unnecessary manual work for a partial delivery or return. Compare order lines, discount allocation and external references as well as the total.

Make the matrix part of change management. A new product type, payment method or fulfilment partner can change the correct destination event. Avoid automatically placing that change in the existing default route. Add the new case, have accounting and operations sign off the route and activate it only after two contrasting tests: one order that must follow the sales-order route and one explicitly permitted to take the direct-invoice route. The absence of an error message does not prove that the accounting record type is commercially correct.

Store the chosen route and rule version for every processed order. This makes a later spot-check verifiable, even after the configuration changes.

Want to distinguish sales orders from invoices at the right process moment? Develop the fulfilment matrix with Yindle.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project