When an inventory count is rejected while warehouse transactions continue, establish which snapshot will govern the recount before entering another quantity. Reusing the first count's movement correction against a refreshed snapshot can count the same receipt or shipment twice and create a false variance.
The decision is specific: keep the appropriate existing baseline under a controlled procedure, or use the configured snapshot-recalculation behavior and rebuild the comparison. Preserve the original observation and explain why the count was rejected. Do not change preferences merely to make an approval error disappear.
Standard NetSuite Inventory Count and the Smart Count SuiteApp have different review and recount processes. Identify which record the user is viewing, the relevant role, and the current status before applying instructions.
For standard Inventory Count, starting the count captures the snapshot. Once the count reaches Completed/Pending Approval, quantities and results cannot be edited in that state. Reject returns it to Started so another count can be conducted. That is a controlled state transition, not approval of the original variance.
Smart Count uses its own review page and recount assignment process. Do not assume the standard Recalculate Snapshot on Inventory Count Reject preference governs every mobile counting application. Record the installed product, release, and applicable preferences in the incident packet.
The standard Recalculate Snapshot on Inventory Count Reject preference allows a new snapshot when a count is rejected. NetSuite then updates snapshot, adjustment quantity, and variance detail using the refreshed on-hand information.
That behavior can be useful when transactions have changed stock during the exercise. It also changes the reference against which the next count must be interpreted. A movement already included in the refreshed system quantity must not be applied again as though the original snapshot still controlled the comparison.
Capture the preference before the test and record whether it was enabled for the rejected count. If configuration changed during an incident, retain both the old and new state and have an administrator establish the actual behavior. A preference name in a procedure is weaker evidence than the resulting snapshot values.
Retain the original snapshot, first physical observation, movement list, rejection reason, and reviewer. Then create a separate recount evidence set with its own baseline and observation time. This can be maintained through the organization's approved evidence process without assuming a particular custom record exists.
The first count may contain useful information even when it is not approved. A wrong unit, omitted bin, or unidentified lot explains why a recount was needed. Replacing the original numbers with the desired result makes that cause harder to investigate.
Mark the superseded calculation clearly. Operators should not have two unlabeled worksheets that both appear current. The reviewer needs to know which evidence supports the proposed adjustment and which remains historical context.
A count starts at 10:00 with a snapshot of 200 units. Before the first observation is completed, a legitimate receipt of 40 units is posted. The first count is rejected because the counter included an adjacent bin outside the scope, so its quantity cannot be trusted.
With the recalculation preference enabled, the rejected count's new system snapshot is 240 units. The recount begins after that refresh, uses the correct bin scope, and observes 237 units with no subsequent movement. The comparison now indicates a three-unit shortage against 240.
If an operator subtracts the earlier 40-unit receipt from 237 again, the entered analytical comparison becomes 197 against 240, creating an apparent 43-unit shortage. The receipt was already included in the refreshed baseline. The extra subtraction is a duplicated cutoff correction.
This example illustrates the control risk, not a universal instruction about what to enter on every count screen. Prove the configured snapshot, detail, and adjustment behavior in a sandbox. Use the raw observation and actual reference time to determine the approved entry.
Before recounting, confirm the item, location, bins, units, lots or serials, and inventory statuses included. Rejection does not automatically establish that the second counter is using the same physical scope.
Check movements after the new baseline separately from those before it. The evidence list should show the physical movement time, system transaction reference, quantity, and affected detail. A transaction entered late can create a timing difference that a timestamp-only report does not explain.
Use a short scoped movement freeze where practical. If activity must continue, assign one person to reconcile post-baseline movement for the recount. Do not ask the counter to remember every receipt and pick while also identifying the rejection's original cause.
Review Snapshot Detail and Variance Detail as well as the top-level quantity. A total can look reasonable while a lot, serial, bin, or status component is inconsistent with current inventory.
Transactions during counting can change the quantity available to support the proposed adjustment. If approval fails, inspect the exact message and relevant inventory detail instead of repeatedly rejecting and approving until something changes. Each new snapshot can alter the comparison again.
A recount that confirms physical quantity does not automatically validate the financial result. The responsible accountant should approve the adjustment account, period, and material value consequences. Keep a technical approval failure separate from an accounting objection to the proposed correction.
In a sandbox, prepare one representative count with the recalculation preference enabled and another controlled test with the alternative configuration. Process a known receipt or shipment between start and rejection. Capture snapshots and variance details before and after rejection.
Write expected results before testing. The test should prove which changes enter the new baseline, which physical observation is used, and how any later movement is handled. Include a second rejection so the team sees that baseline management is not a one-time concern.
Do not turn this into a recommendation to disable recalculation universally. The appropriate configuration depends on the supported operating method. The acceptance criterion is that the reviewer can explain the result reproducibly under the chosen policy.
If Smart Count is in use, test its Recount action and employee assignment through the supported review process. The relevant confirmation preference enables the employee-assignment prompt. Confirm which worker receives the task and how it appears in the mobile task list.
Include an absent counter and a paused count. A task assigned incorrectly can delay resolution while stock continues moving. The supervisor should have a supported way to identify and reassign outstanding work without creating a second uncontrolled count.
Validate movement notifications in the installed Smart Count configuration. They help handle recorded on-hand changes, but an unrecorded physical movement still requires operational evidence. Avoid applying the standard count's snapshot procedure to Smart Count simply because both use the word recount.
After approval, inspect the count history and every related adjustment. Standard counts can generate positive and negative adjustments for different differences, so do not assume there will always be exactly one correction record.
Reconcile the resulting item-location and inventory-detail quantities with the approved recount evidence. Confirm that no manual adjustment was entered separately for the same shortage while the count remained pending. That parallel correction can duplicate the effect.
Close the incident with the rejection cause, chosen baseline policy, final recount evidence, adjustment references, and preventive action. CuriousRubik's NetSuite support services can be approached with those records for an account-specific review of a recurring count-approval problem.
It returns the count to Started so another count can be conducted. If the snapshot-recalculation preference is enabled, the system refreshes the baseline and related variance details. Confirm the actual preference and resulting values.
A refreshed snapshot may already include that movement. Applying it again can create a false variance. Separate movements before the new baseline from those afterward and retain the raw recount observation.
Not in that standard count state. Use the supported review and rejection process when a recount is needed. Do not create a separate manual adjustment just to work around the count's state.
Do not assume so. Smart Count has a separate review and recount-assignment flow with its own preferences. Identify the installed counting application and test its actual behavior before using a procedure.
Review all related adjustments, resulting inventory detail, and any parallel manual correction. Confirm that the approved difference was applied once and that finance has reviewed material value and period effects.