The first implementation

Everything was in Intacct except the factory

The client runs a make-to-stock rubber operation: raw material compounded and formed into finished product against known recipes, across several stock locations, with work in progress at any moment.

Intacct held the accounting properly and was not in question. What it could not hold was the day: a run confirmed at the machine, components staged for a job, a pallet moved between warehouses. Those events reached the system late, through people who had not witnessed them.

The client had already reached the conclusion most manufacturers on Intacct reach — that the answer was a manufacturing system — and had already ruled out the version of that answer where the books move.

We built the wrong thing first, and said so

Our first attempt was a bespoke manufacturing application written directly over the Intacct gateway. Works orders, bill-of-materials explosion, backflush, work in progress — all hand-built.

It worked, and we retired it before it ever carried a day of the client's live production.

Because nothing had gone live, there was no data to migrate and nobody to retrain. The bespoke application was rewritten into what it should always have been: a requirements document.

Masters in first, postings second

The order was deliberate. Nothing posts to a live company until the mirror of that company is proven correct.

A one-way mirror from Intacct

Items, warehouses, bins, units of measure with their conversion factors, suppliers, purchase orders with outstanding quantity, entities and product line structure — read-only in Fuse, refreshed on a schedule. Precision, currency and item grouping are read from Intacct rather than chosen.

The posting layer

Production posts as a backflush decrease plus a run increase, inside one Intacct transaction so both legs commit or neither does. Transfers post the same way. Intacct is called before the Fuse document stands, so a rejection leaves nothing behind on either side.

The audit trail

Every write recorded in full — function, document, entity, duration, the key Intacct returned, and the complete request and response with credentials stripped. No role can edit an entry.

The undo path

Cancelling a posted movement writes a reversing pair into Intacct, dated to the original posting date. Getting this right meant discovering that a reversal is not the forward posting negated — the cost rides the increase leg, so reversing by mirroring returns the quantity and loses the money.

Four screens, then a fifth for the floor

Works Orders, Issue to WIP, Item Transfer and Stock Control on the desk; then a shop-floor screen carrying the same three movements in a form a supervisor uses at the machine — a scan, a quantity, one button. Both routes build the same document and post through the same code.

Production runs, transfers and their reversals have been posted end to end against the client's Intacct implementation company — real documents, real Intacct document numbers, not a sandbox demonstration.

The client kept four things in Intacct, on purpose

Receipting, stock adjustments, cycle counting, and maintenance of items, warehouses, suppliers, bills of materials and purchase orders all stayed where they were.

This was their operating preference, and Fuse enforces it rather than merely documenting it: the receipting and adjustment paths are blocked outright, including the side doors — a purchase invoice that updates stock is refused the same way a purchase receipt is. A user who tries is told where to go instead.

A movement Intacct never sees is the one failure the whole product exists to prevent. So the paths that could produce one are closed, not discouraged.

All four are available to a client who wants them. Each is a build, quoted as one.

Two things worth carrying to the next client

Audit the client's tracking flags early

A few dozen of this client's items still carried bin tracking in Intacct that their operation no longer uses. Transfers of those items are rejected by Intacct until the data is cleaned — correctly so. It is an afternoon's work when found in week one and a go-live delay when found in week ten.

Decide the site's own housekeeping up front

Outgoing email, user onboarding and password delivery are ordinary platform setup, and are easy to leave until the week people need logins. Put them in the plan next to the integration work, not after it.