Understand how inventory transaction records work in Sanka, including inbound, outbound, adjustment, status, valuation, barcode operations, and AI checkpoints.
Last updated: May 29, 2026
The Inventory Transaction object stores the movement history behind inventory balances. Use inventory transaction records to explain why stock increased, decreased, moved, or was adjusted for an item at a location.This reference explains what an inventory transaction should contain, how it changes inventory, and what to check before posting, editing, importing, scanning barcodes, or troubleshooting stock movement with AI, actions, workflows, CSV, integrations, or manual entry.
Claude/Codex
Review this inventory transaction before posting it. Show item, inventory record, location, transaction type, inventory bucket, quantity, unit price, transaction date, source order or purchase order, barcode evidence, duplicate risk, and missing fields. Do not post or update stock yet.
Reviewing inventory transactionI reviewed the transaction. Please confirm item, location, movement type, quantity, stock bucket, source record, and duplicate risk before posting.
Ask for another transaction check...
What an inventory transaction represents
An inventory transaction represents a stock movement or adjustment. It is the audit trail behind the current inventory balance.Common transaction types include:
Inbound: stock is added, such as purchase receiving, customer return, or manual restock
Outbound: stock is removed, such as shipment, consumption, transfer out, or manual issue
Adjustment: stock is corrected after count, damage, loss, valuation review, or operational correction
Common fields include:
Transaction ID or record ID
Related inventory record
Item, item variant, and location
Transaction type
Inventory bucket, such as available, committed, or unavailable
Quantity and resulting quantity
Unit price, total price, or average price when valuation is used
Transaction date
Status, such as draft, processing, delivered, or canceled
Transactions should explain the movement. Inventory records show the resulting balance.
Use statuses carefully
Transaction status helps separate planned movement from completed movement.
Draft: not ready to affect final stock reporting
Processing: being handled by warehouse, fulfillment, or another operation
Delivered: completed movement that should be considered in stock review
Canceled: movement should not be treated as active evidence
Your workspace may decide which statuses count toward stock calculations or reports. Before calling a quantity wrong, check whether the transaction status is included in your team’s stock process.
Review movement before posting
Stock movement can affect sales, fulfillment, purchasing, and accounting. Review the evidence before posting or correcting transactions.
Sample prompt
/sanka Check this inventory transaction before posting. Compare item, location, transaction type, inventory bucket, quantity, unit price, date, source order or purchase order, existing inventory balance, duplicate transactions, barcode evidence, and permissions. Do not post or change stock yet.
For barcode or mobile warehouse operations, confirm the scanned code matched the intended item and location before saving the movement.
Expected behavior
When an inventory transaction is created or posted successfully:
It appears in the Inventory Transaction object list unless it is archived or filtered out by the current view
Related inventory, item, location, movement type, stock bucket, quantity, price, date, status, owner, and source are saved
Inventory balance can update according to the transaction type, status, and workspace rules
Source records such as orders, purchase orders, receiving, returns, slips, or barcode scans can provide evidence
Reports can use the transaction to explain stock movement and valuation
CSV imports, integrations, actions, workflows, barcode scans, and AI-assisted changes still follow required fields, permissions, matching rules, and validation
Creating a transaction does not always mean the movement is final. Draft, processing, canceled, filtered, or mis-associated transactions may not affect the stock view a user expects.
Troubleshooting
Stock did not change after a transaction
Check transaction status, transaction type, inventory bucket, quantity, related inventory record, workspace stock calculation rules, and whether the current view is showing the expected location.
Stock changed in the wrong direction
Check whether the transaction was inbound, outbound, or adjustment. Also confirm whether a return, transfer, or correction was entered as the wrong movement type.
The transaction is linked to the wrong item or location
Check item, SKU, barcode, inventory record, warehouse, location, import mapping, integration mapping, and any changes made after the transaction was created.
A transaction was duplicated
Check CSV import history, barcode scan history, workflow/action runs, integration syncs, source order or purchase order, and whether the same movement was recorded manually and automatically.
Unit price, total price, or average price looks wrong
Check unit price, quantity, currency, transaction type, purchase receiving price, adjustment reason, and whether valuation should be calculated from transaction history.
AI cannot decide whether this is a bug
Ask AI to compare the transaction, source evidence, inventory record, item, location, stock bucket, transaction status, related order or purchase order, import history, barcode evidence, permissions, and audit trail. Treat it as a possible bug only after confirming the movement setup and source evidence are correct.
Checkpoints
Before posting, editing, importing, canceling, barcode-scanning, or replying to an inventory movement support case, check item, location, inventory record, transaction type, stock bucket, quantity, price, date, status, source evidence, duplicate risk, permissions, and audit trail.
