Cin7 Core said the supplier didn't exist. It was right there on my screen.

Last Monday a purchase order to one of our packaging suppliers came back with a 400 and this:

Supplier with specified 'Name' not found

I had that supplier open in the next tab. Active, current, years of received purchase orders sitting against it. The name on my screen and the name in my payload matched character for character, as far as I could tell by reading them.

Twenty minutes went by while I assumed I had broken my own code. Then I queried the Cin7 API directly for the supplier by name and got Total: 0. Queried it again with a single space in front of the name, and the record came straight back.

The name stored in Cin7 is Packaging Co, with a leading space. Cin7's supplier screen renders that identically to the version without, because HTML collapses leading whitespace before it paints anything. So does every other web screen in my stack. No amount of squinting at the two tabs was ever going to find it.

I run Personalised Favours, a Sydney-based manufacturer on Cin7 Core and Shopify. A bit over 15,000 sellable variants, 747 supplier records, and roughly 700 SKUs I actively manage. When something in the purchasing path fails in a way that looks impossible, it tends to have been failing for a while, so I went looking for how widespread this was.

The check took ten minutes

I pulled all 747 supplier records and ran two tests on the name field:

name !== name.trim()        // leading or trailing space
/\s{2,}/.test(name)         // doubled space inside the name

Seven records failed. Just under one percent of the account. The one blocking my purchase order carried the leading space. The rest were trailing spaces, and a doubled space in the middle of a trading name where somebody had typed over an old spelling and left the gap behind.

None of the seven look wrong on screen. They can't. The defect is invisible in the interface that created it, which is what lets it sit in an account for years.

All seven were fixed that afternoon. One by hand, the other six by sending the record back through the API unchanged except for a trimmed name. I backed up the originals first, because a supplier record carries payment terms and account codes and I was not about to learn a lesson about bulk updates on the same day. Re-ran the audit afterward: zero.

Six of the seven weren't blocking anything

Only one supplier was failing a purchase order. I fixed the other six anyway, because the purchasing path is not the only place a supplier name gets compared to a supplier name.

Your accounting system matches an incoming bill to a contact record by name. A trailing space there doesn't throw an error, it quietly opens a second contact and splits that supplier's payables across two of them. Same story with a CSV import, which will cheerfully create a brand new supplier when it can't match the name it was given. Then there is every spreadsheet you keep with a lookup against a name column, and the month-end reconciliation where a supplier's own statement header gets matched against your list.

Duplicates don't announce themselves. You find one when a supplier calls about an invoice you're certain you paid, and then you spend a morning working out which of the two records the payment went to.

The tell that gave it away

The useful part of Monday was the asymmetry in how our own scripts failed.

Raising a purchase order for a brand new supplier worked perfectly. The lookup on that path trims both sides before it compares, so whitespace never mattered there. It was only suppliers we had ordered from before, the ones where we already held a full purchase history, that failed.

That is backwards from what you would expect, and it pointed straight at the cause. The code was resolving a valid internal supplier ID out of the purchase history, then discarding it and posting the name string instead, because Cin7's API accepts either one. The path that already had the right key in hand was the only path throwing it away.

The fix was one field. Send the supplier's internal ID, not the name. Whitespace can't reach it, and it survives a supplier being renamed in Cin7 six months after the name was cached, which is a failure I hadn't gotten around to being bitten by yet.

If the system gives you an ID, store the ID and send the ID. The name is for humans to read.

That is not a complaint about Cin7. The API documents the ID field and takes it in preference to the name. I wasn't using it, and I suspect most people integrating anything with Cin7 aren't either, because the name is the field you can see in both windows and therefore the field you trust. Mine was the one field where my eyes and my code could disagree without either of us noticing.

What to do this week

Export your supplier list from Cin7 Core. Run the two whitespace checks on the name column, then sort the list and read it for near-duplicates. On 747 records that took ten minutes and found seven things to fix.

Then go and look at whatever you have built or bought that joins on a name instead of an ID. Start with bill matching into your accounting system, because that one costs you money quietly, without ever throwing an error you can see.

And fix the data before you go hunting for the bug. I had that order the wrong way around on Monday and it cost me an afternoon.

Stocura sits on top of your Cin7 Core data and raises a draft purchase order into Core in one click, grouped by supplier so everything due from one supplier lands on a single order. Each SKU carries the supplier's own product code, so the PO reads in their language instead of yours. Lead times are learned from your actual purchase order history rather than the estimate you typed in at setup, and PO changes you make in Cin7 flow back within about three hours.