Cycle Count & Inventory Audit Manager

The annual wall-to-wall count is the most expensive way to find out your inventory is wrong. The warehouse stops, shipping stops, a weekend disappears, and the outcome is a single large adjustment that tells you nothing about which items drift, which bins are mislabelled, or which process is leaking stock. Meanwhile the accuracy problem you actually care about is the daily one: a picker goes to a bin, the quantity is not there, the sales order slips, and nobody finds out until the customer calls.

NetSuite gives you an Inventory Count record and, on accounts with the relevant features, a Smart Count that locks only the items being counted rather than the whole location. Those are the right primitives. What they do not give you is the operating system around them: a plan that decides which items get counted how often, task generation and assignment, scanner-driven entry that understands bins and lot numbers, a variance calculation that survives stock moving during the count, a recount loop with tolerances, and reporting that shows whether accuracy is improving.

What ECOSIRE builds

ECOSIRE builds a cycle count and inventory audit layer inside your own NetSuite account using SuiteScript 2.1, custom record types, Map/Reduce scripts, Suitelets and RESTlets. It sits on top of standard NetSuite inventory records. Adjustments post as ordinary Inventory Adjustment transactions with the correct adjustment account, subsidiary, department, class, location and inventory detail, so your costing, GL and audit position stay conventional.

Everything is delivered as an SDF project and an unmanaged bundle deployed to your account. There is no external database, no hosted portal and no data leaving NetSuite.

The count plan

A Count Plan custom record defines the policy: which locations are in scope, how items are classified, and how often each class is counted. Classification can be driven by an ABC field on the Item record, by value or movement calculated from a saved search over transaction history, by item type, by bin, by inventory status, or by a custom segment such as a product line or a regulatory category. Each class carries a target frequency and a coverage goal, for example every A item counted monthly and every location touched at least once a quarter.

The plan is a record, not code, so operations can change frequencies without a deployment. Changes are versioned so a later plan edit does not make last quarter's coverage report inconsistent.

Generating and assigning count tasks

A scheduled Map/Reduce script reads the plan, works out what is due, and creates Count Sheet records with child Count Line records. Each line captures the item, the bin, the inventory status where applicable, and a snapshot of the system quantity and the timestamp at which the sheet was issued. That snapshot is what makes the rest of the process defensible.

Sheets are assigned to counters by Employee record, and the assignment respects location and role so a counter only sees their own work. Sheets can be generated blind, hiding the expected quantity, or informed, showing it, per plan and per class, because the right answer differs between a high-value serialised item and a bin of fasteners.

Counting on a scanner or phone

Counters work in a Suitelet built for a small screen and a barcode wedge, or through a RESTlet if you already run handheld terminals. Scanning a bin barcode filters the sheet to that bin; scanning an item UPC or internal barcode selects the line; lot numbered and serialised items prompt for the lot or serial and validate it against the Inventory Detail records actually present, so a counter cannot invent a lot that does not exist in that location.

Entries are saved line by line rather than in a single submit, so a dropped connection does not lose an hour of counting. Every entry records the counter, the device session and the timestamp.

Variance that accounts for movement

This is the part that makes counting without freezing a location honest. Between the moment a sheet is issued and the moment it is posted, real transactions occur: item fulfillments, item receipts, inventory transfers, work order issues and assembly builds. A naive comparison of counted quantity against current system quantity will report variance that is really just movement.

The reconciliation script reads the inventory transaction history for each counted item, bin and lot between the snapshot timestamp and the posting timestamp, and adjusts the expected quantity accordingly before computing variance. The result is a variance figure that reflects genuine discrepancy, and a line-level explanation showing which transactions were netted out.

Posting adjustments correctly

Variance is then run through your tolerance policy. Inside tolerance, defined by unit count, value, or percentage per item class, the line auto-posts. Outside tolerance, the line is flagged for recount and a second sheet is generated for the same locations. After a configurable number of recounts, or above a value threshold, the line escalates to a supervisor for approval before posting.

Approved variances post as Inventory Adjustment transactions with the adjustment account from the plan, full segment coding, an open accounting period check, and the correct inventory detail for lot, serial and bin managed items. Nothing posts silently and nothing posts to a closed period.

Accuracy reporting

An append-only audit record captures every count event: sheet, line, counter, snapshot quantity, counted quantity, netted movement, final variance, tolerance decision, approver and posting transaction. On top of it sit saved searches and dashboard portlets for accuracy by location, by bin, by item class and by counter, coverage against plan, recount rate, and net adjustment value by period. That is the evidence an external auditor asks for when you tell them you no longer do a wall-to-wall count.

Who this is for

Distributors and manufacturers running NetSuite with bin management or multiple locations, businesses whose auditors accept cycle counting in place of a full physical count provided coverage and accuracy are demonstrable, and any operation where a shutdown count costs more than the discrepancies it finds. If you run one small location and count it in an afternoon, native Inventory Count is sufficient and we will say so.

How delivery works

This app is build-to-order. First a scoping call covering your locations, bin and inventory status setup, item classification, who counts, what hardware they use and what your tolerance policy should be. Then a fixed written quote and scope. Then the build, typically two to four weeks depending on scanner integration and the complexity of your classification rules. Installation goes into your sandbox account first so counters can run a real sheet against real data before anything touches production, followed by a production install in an agreed window and handover of the SDF project and bundle. A defined support window covers defect fixes and tuning after go-live.

What this is not

It is not a warehouse management system, not a hosted service, and not a subscription. It is a customisation of your NetSuite account, built once to your process, which you own and can maintain.