Cycle Count and Inventory Audit Program

Why the annual stocktake keeps failing you

SAP Business One gives you an Inventory Counting document and an Inventory Posting document. That is enough to run a stocktake. It is not a counting program.

What it does not give you is a schedule. Nothing in the standard system decides that your A-class items should be counted twelve times a year and your C-class items once, generates this week's list, assigns it to a counter, and tracks whether the count actually happened. So most SAP Business One sites do what the software implies: close the warehouse for a day or two at year end, count everything, and post whatever the difference is.

That annual event has three costs. The obvious one is the shutdown. The second is that a variance found in December tells you nothing about when the stock went missing — the trail is eleven months cold, so the posting becomes a write-off rather than a corrected process. The third is the one auditors raise: the standard document holds the counted quantity, but it does not hold who counted it, whether they could see the system quantity while counting, who approved a six-figure adjustment, or why.

Meanwhile the operational damage runs all year. A picker finds an empty bin on an item the system says has forty units. Purchasing reorders against a quantity that was wrong in March. Nobody finds out until the shutdown.

What ECOSIRE builds

ECOSIRE builds a cycle counting and inventory audit program as a native SAP Business One add-on. It generates the work, controls how the count is taken, routes the variance, and keeps the evidence — while the actual stock correction posts as a standard SAP Business One Inventory Posting so your General Ledger and your auditor see nothing exotic.

ABC classification that recalculates itself

Items are classified by a rule you set — annual consumption value, movement frequency, unit cost, or a manual override for controlled or high-theft goods. The classification runs on a schedule against actual Inventory Transaction history rather than a one-time list, and the resulting class is stored on an Item Master UDF so it is visible and reportable everywhere. Class drives count frequency: A twelve times a year, B four, C once, with the numbers configurable per Warehouse because a bonded store and a consumables cage do not deserve the same attention.

Count scheduling and sheet generation

The scheduler builds each period's count population from the classification, the last-counted date held per Item and Warehouse, and any triggers you enable — a negative on-hand, a stock-out with open demand, a bin picked to zero, or a manual request from a supervisor. Count sheets are generated as a UDO document with lines per Item, Warehouse, bin location and, where relevant, Batch or Serial Number. Sheets can be printed as Crystal Reports for paper counting or opened on a browser-based count screen for handheld and tablet entry.

Blind counts and recount control

By default the counter never sees the system quantity — that is the entire point of blind counting, and it is the control most spreadsheet-based programs quietly abandon. Variances beyond a threshold you configure automatically raise a second count, optionally routed to a different counter, before any adjustment is proposed. First count, recount and final quantity are all retained; the add-on does not overwrite the first number with the corrected one.

Variance approval

Proposed adjustments are routed through the standard SAP Business One approval procedure framework with thresholds by value, by quantity percentage, by item class, or by Warehouse. A supervisor may clear a small discrepancy on a C-class consumable; a five-figure adjustment on controlled stock goes to finance. Reason codes come from a User-Defined Table you maintain, and a reason is mandatory above a configurable value so the write-off report is analysable rather than a single line called "stock adjustment".

Posting and the ledger

Once approved, the add-on creates the standard SAP Business One Inventory Posting document through the DI API, honouring your valuation method, your inventory adjustment account determination, and Batch or Serial allocation. The resulting Journal Entry is an ordinary one. Nothing in the trail requires the add-on to be installed in order to be audited later.

Audit evidence

Every count carries who was assigned, who counted, when, from which device, what the system quantity was at the moment of the snapshot, the first and second counted quantities, the approver, the reason code and the resulting document numbers. Reports cover count accuracy by counter and by warehouse, coverage against plan, aged uncounted items, adjustment value by reason, and a period-by-period inventory accuracy trend — the evidence pack an external auditor asks for when you propose to stop doing a full physical count.

Where it plugs in

Reads and writes go through the SAP Business One Service Layer and the DI API. No SAP tables are modified. Extension objects are UDFs, UDTs and UDOs, and approvals reuse your existing SAP Business One approval procedures and authorisers.

Who this is for

Distributors and wholesalers, third-party logistics operators, manufacturers with raw-material and WIP stores, retailers with a central warehouse, spare-parts and equipment dealers, and any SAP Business One site whose auditor has asked for cycle counting as a condition of dropping the full annual physical count.

How delivery works

This app is built to order. It does not exist as a shrink-wrapped product waiting for a download link.

1. Scoping call. We review your warehouse and bin structure, whether you use Batch or Serial management, your current counting practice, your approval hierarchy, and your SAP Business One version, patch level and database platform.

2. Fixed quote. You receive a written specification — classification rules, count frequencies, count-sheet formats, approval thresholds, reports — with a fixed price and delivery date. The listed price is a starting point; your quote reflects the scope you approve.

3. Build. Development runs against a copy of your company database so warehouse codes, bin structures, UDFs and item groups match your live environment.

4. Install in test, then production. Installation goes into your test company first. You run a full count cycle there against real data, confirm the postings and the approval routing, and only then do we install into production on a date you pick, with a documented rollback.

5. Support. A support window follows go-live for defect correction and configuration tuning, extendable if you want ongoing changes.

Typical lead time is one working week from signed quotation.