The inventory model
Two facts about VeraCore's inventory feed shape everything on the Inventory and Inventory Ledger tabs. Neither is obvious, and both cause confusion the first time someone compares a number here against a number in VeraCore.
- VeraCore never exposes raw on-hand. Every quantity it publishes has already had something subtracted from it.
- VeraCore publishes no movement events. There is no "5 units picked at 14:02" feed to consume.
Everything below follows from those two.
What the numbers actually mean
VeraCore reports two quantities per item per facility, and both are derived:
| VeraCore field | How VeraCore computes it |
|---|---|
available | on-hand − marked − unavailable |
availableWithReserved | on-hand − unavailable |
Marked is stock allocated to orders already in the warehouse's queue. Unavailable is stock that exists but cannot be sold — damaged, quarantined, held.
The true physical count never appears in the feed. The closest thing available is availableWithReserved, so that is what SKU.io stores in its On Hand column:
| SKU.io column | Source |
|---|---|
| On Hand | VeraCore's availableWithReserved — physical stock, less anything unavailable |
| Available | VeraCore's available — free to sell right now |
| Committed | On Hand − Available, never below zero — effectively VeraCore's marked quantity |
| Incoming | Always 0 |
It is on-hand minus unavailable. If your 3PL has quarantined stock, SKU.io's On Hand will be lower than the number a warehouse manager reads off a shelf — and both are correct. This is why the Discrepancies tab labels VeraCore's figure VeraCore Available rather than "Actual": there is no figure in the feed that deserves the word "actual".
Why Incoming is always zero
VeraCore's inventory feed carries no incoming dimension at all — it describes what is in the building, not what is on its way. Goods heading to the warehouse are tracked separately, as expected arrivals, and they book no stock until VeraCore receives them. The column exists for consistency with other providers and stays at zero here.
Per-facility figures, and the aggregate fallback
The preferred feed is the detailed one, which returns a balance per item per facility. That is what fills the Warehouse column and lets a multi-facility 3PL show you where stock actually is.
Not every VeraCore installation offers it. When it is unavailable, SKU.io falls back to VeraCore's aggregate feed — a single total per item, with no warehouse dimension whatsoever. Those rows are:
- Pinned to the connection's linked 3PL warehouse, because they have to land somewhere;
- Given Committed = 0, because the aggregate feed does not report a marked quantity;
- Flagged so the Source column can say the breakdown is unavailable.
That flag matters. Without it, a single-warehouse-looking table would quietly imply "all of this stock is in that one building, and we checked" — when the truth is "we could not see the breakdown". The two are very different answers to the same question, and the UI is built to keep them distinct.
The ledger is a diff, not a transaction log
Because there is no movement feed, the Inventory Ledger is derived: on each mirror run, SKU.io compares the balances it just fetched against the balances from the previous run and writes a row for every difference.
| Source | What it means |
|---|---|
| First Observation | This item/facility pair had never been seen. There is no prior snapshot, so there is nothing to compare. |
| Snapshot Change | The quantity differs from the previous snapshot. |
| No Longer Reported | The pair was in the previous snapshot and is absent from this one. |
Three consequences follow, and every one of them has surprised somebody:
- Many real movements collapse into one row. If forty units ship and twenty-five arrive between two snapshots, you get a single row showing −15. The ledger records net change per snapshot interval, not events.
- Timing is snapshot timing. The Observed At column is when SKU.io looked, not when anything happened at the warehouse.
- Pruning is free. Deleting old ledger rows discards derived history, never stock. Retention is a housekeeping setting, not an accounting one.
No — and it is worth being explicit about this. The mirror runs once a day because VeraCore's own guidance is to export balances once a day, after the last order batch has processed. Walking every Offer is expensive on both sides. A daily ledger with coarse rows is the intended trade; the ledger is a trend and audit tool, not a replacement for movement history.
How discrepancies are computed
The Discrepancies sub-tab compares one number from each system:
- SKU.io Qty — what SKU.io believes it has in the mapped warehouse.
- VeraCore Available — what VeraCore reports as free to sell.
The difference is shown as Discrepancy, and multiplied by unit cost as Value, so you can prioritise the ones that matter financially rather than the ones that are merely numerous.
A discrepancy is not automatically an error. Common innocent causes:
| Cause | Why the numbers differ |
|---|---|
| Marked stock | VeraCore has allocated units to orders it has not shipped yet, so its Available is lower. |
| In-flight orders | SKU.io has deducted for a shipment VeraCore has not reported, or the reverse. |
| Snapshot timing | The mirror ran at 02:00; it is now 16:00 and the day has happened. |
| Unmapped kit components | A component's stock is held under a different offer. |
Nothing is corrected automatically. SKU.io never writes stock back to VeraCore, so the only way to resolve a real difference is to adjust the SKU.io side — which is what creating a stock take from discrepancies is for. The stock take makes the change auditable rather than silent.
The four segments
The Inventory tab splits every item into exactly one of four buckets, which together answer "is the mapping complete and do the numbers agree?":
| Segment | Meaning | What to do |
|---|---|---|
| All Inventory | Every mirrored balance | Browse |
| Discrepancies | Mapped, but the numbers disagree | Investigate, then stock take |
| SKU.io Only | SKU.io holds stock VeraCore has never reported | Usually a missing mapping, or stock genuinely held elsewhere |
| VeraCore Only | VeraCore reports an offer no SKU.io product is mapped to | Map it — see Map an offer to a product |
The two "only" segments are mapping problems wearing an inventory costume. Both usually shrink to near zero once the catalogue is mapped, which is why mapping is worth finishing before you start reading discrepancies seriously.
For what each column and filter does, see the tabs and columns reference.