Invoicing accuracy

Right. Not all of them, but enough to matter, and there was no way to tell which.

Right, and we take responsibility for it. Until 4 August the ordering app fell back to the standard catalogue price when it could not find a customer’s own agreed price. Those wrong prices then travelled all the way to the invoice.

A second, quieter version of the same thing: where a customer had no price at all for a product, the line went through at zero.

Right, and we take responsibility for it. Every time a customer edited an order before the cut-off, the system raised a fresh invoice instead of updating the one it had already made. Nothing removed the earlier one.

Two different things sit underneath this, and only one of them is a fault.

Right, and we take responsibility for it. The email was never written onto the invoice, so QuickBooks could not send it without someone typing the address in first. Three customers had no email held anywhere in the app either.

When a customer changed their order, the system raised a brand new invoice rather than amending the one already there. Every edit made another one.

This is the single biggest cause of the mess in the books, and it is why so much time was going into deleting duplicates by hand.

A product created in the ordering app was not created in QuickBooks. When anyone ordered it, QuickBooks refused the entire invoice, not just that line. One unmatched item lost the whole order.

Eighteen products had built up this way, and the app had no way of telling anyone.

The email address was never being written onto the invoice, so QuickBooks could not send it without someone typing the address in first.

Three customers also had no email held anywhere in the ordering app, so there was nothing to write. Those have been filled in from QuickBooks' own records.

If an order contained a product QuickBooks did not recognise, the whole invoice was refused. The refusal was recorded, but nothing ever went back and tried again once that product was added. The system could see the problem. It could not recover from it.

It can now. Every half hour the system checks for orders that were refused, confirms the cause has actually been fixed, and puts them through. Before it creates anything it looks in QuickBooks to see whether Shelly has already raised that invoice by hand, and if she has, it leaves it alone.

An order placed on Wednesday evening for Thursday's bread carried Wednesday's date. Not always — it depended on whether a date label made it through the handover, and often it did not, in which case the system quietly used the order date instead.

We were going to ask Shelly which she preferred. We did not need to: the books already answered it. Invoices carrying the delivery date were mostly kept. Invoices carrying the order date were almost all deleted.

The ordering deadline is enforced on our server against Barbados time. If that check could not read the configured cut-off, it let the order through rather than stopping it.

That is the wrong way round. An order accepted after the deadline lands in the bakery's morning production run without warning. The check now refuses the order and tells the customer to ring the bakery, on both the wholesale and the Italia ordering paths.

We were going to ask and then decided we could work it out. We read it from your own behaviour: invoices dated the delivery date were mostly kept, invoices dated the order date were almost all deleted. So we changed the system to use the delivery date.

If that reading is wrong, tell us and we will change it back the same day. It is one setting, not a rebuild.

Where our invoice is missing and one of yours sits within a day of it for the same customer, we count that delivery as covered and stop worrying about it.

Six August invoices carry a quantity that does not match what the customer ordered. That could be us sending the wrong number, or you correcting a short delivery. The two look identical from where we sit.

Seventeen August delivery days had an invoice raised and then removed, with nothing put back yet. We are treating those as work in progress on your side rather than deliberate write-offs, and the morning check will tell us when a replacement appears.

If any of them were written off on purpose, say which and we will stop counting them.

Where the two systems disagree on whether a product carries VAT, the invoice follows QuickBooks. Nobody told us to do that. It was the safer default, and it means your ledger has not been contradicted, but it is a decision we made rather than one you gave us.

The 16 products where they disagree are listed in the next section.

These are orders the system refused because of an unrecognised product, and never tried again. The goods went out. No invoice was ever raised for them, by us or by hand.

We can put all seven through in a few minutes, correctly dated and correctly priced. We have not, because Shelly may already be part-way through keying some of them, and the last thing she needs from us is a second copy of an invoice she has just written.

Separate from the above, and not a fault in the system: an invoice was raised for these deliveries and later deleted from QuickBooks, and no replacement has appeared. Most are recent, so this may simply be work in progress. We are listing them so that none is lost by accident.

For 16 products, the ordering app and QuickBooks hold different views on whether VAT applies. Where the two disagree, the invoice follows QuickBooks.

We need a ruling on which is correct for each, and then we will make both systems agree and keep them that way. Until then the morning check reports the disagreement every day so it cannot drift further.