FRAMEWORK

Scoping a Cin7 project: who does what

A Cin7 build is three kinds of work wearing one project name. There's the storefront and the buying experience. There's the integration between the storefront and Cin7. And there's configuration inside Cin7 and the accounting system beside it, which is where stock takes, locations, and month-end live. Treating those as one job is how timelines slip, because the third kind needs someone who runs Cin7 for a living.

Why does a Cin7 project have more owners than usual?

Because Cin7 doesn't own finance, a Cin7 project has more moving parts than an ERP project of the same size. Cin7 holds stock and orders. Xero or QuickBooks holds the ledger. The storefront holds the buying experience. Each of those has a boundary with the other two, and every boundary needs a person whose name is on it. Projects that skip this step don't fail loudly. They arrive at go-live with two systems each holding a slightly different version of a customer, and nobody able to say which one is right.

What do you settle before design starts?

1. Who owns the ledger? Xero and QuickBooks are the usual answers, and the choice changes how invoices, credit notes, and tax behave. It also decides who is responsible when a month doesn't reconcile.
2. Who owns the customer record? If the storefront can create a customer and Cin7 can create a customer, you need a rule for which wins, or you'll be merging duplicates by hand within a quarter.
3. Who owns price? Cin7 holds price tiers and customer-specific pricing. The storefront can hold its own. One of them has to be authoritative, and the other has to read.
4. Who owns the stock position? This one is non-negotiable. Cin7 is the answer, and every channel reads from it. The moment a channel keeps its own number you have a reconciliation problem instead of an inventory system.

What sits on the commerce side?

The storefront, the catalogue structure, and the buying experience. Configuring how products and inventory flow between Cin7 and the storefront, including which fields map to what and what happens when a sync fails. Anything the connector doesn't reach, which usually means contract pricing rendered per account, quotes and approvals, and deciding which location ships an order. Search, merchandising, and the checkout. This is our work, and it's the part of a Cin7 project that looks like every other commerce project we run.

What sits on the Cin7 and accounting side?

Setting up the chart of accounts and connecting Cin7 to Xero or QuickBooks so the ledger balances. Configuring locations, warehouses, and bins, and the rules for moving stock between them. Running the first stock take and the ones after it, until the counts are trusted. Month-end reconciliation, and coaching the team through it until they don't need coaching. Purchase order and supplier setup. Deciding whether B2B runs through Cin7's own B2B portal or through the storefront, which is a real fork with cost on both sides.

That work needs someone who administers Cin7 daily, which is a different professional from a commerce architect. On engagements where it's in scope we bring in a Cin7 specialist to own it, and we say so in the statement of work instead of absorbing it and hoping. A prospect is better served by two named owners than by one agency claiming both.

Should B2B run through Cin7's portal or the storefront?

Cin7 sells a B2B portal, and for a wholesale operation that mainly needs authenticated reordering against account pricing, it's often the right answer and the cheapest one. It stops being the right answer when the buying experience needs to look and behave like your brand, when the same cart has to serve retail and wholesale, or when approvals and quoting sit in the middle of the sale.

The wrong version of this decision is making it on aesthetics. The right version is listing what the buyer has to be able to do, then checking that list against the portal before assuming a storefront.

Who answers at 2am?

Three different things break in a Cin7 build, and they have three different owners. A fault inside Cin7 is Cin7's, and it goes to Cin7 support. A fault in the storefront or in the integration is ours. A process problem, where the system worked and the data was wrong, belongs to whoever owns the relevant boundary from the four questions above. Any engagement worth signing states which of those you're buying, what the response time is, and who to call when nobody's sure which category it falls into.

That last case is the common one, and it's why the boundary owners matter more than the response time.

What to take from this

1. Name four owners first – Ledger, customer record, price, stock. Do it before design, and put the names in the scope.
2. Cin7 configuration is a specialist trade – Stock takes, locations, and month-end need someone who runs Cin7 daily, not a commerce architect with good intentions.
3. Test the B2B portal before building past it – List what the buyer must do, then check the portal against that list. It's frequently enough, and it's cheaper.
4. Sort support into three buckets – Cin7 faults, build faults, and process problems. The third is the most common and the least often assigned.

For what Cin7 runs and where accounting sits, start at the Cin7 ecosystem hub. For the projects with no storefront in them at all, see Cin7 without a storefront.

Frequently Asked Questions

Next Step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.