Troubleshooting
Most VeraCore problems look identical from the outside — something did not sync — and have completely different causes. This page is organised by symptom, so you can start where the problem is visible rather than where it originates.
Two things are worth knowing before you start.
Half of what looks broken is a mapping. VeraCore and SKU.io each have their own identifiers for products, warehouses, carriers, and channels. Where those are not matched up, data arrives and then has nowhere to go. It is not lost; it is unattached.
The other half is your 3PL's configuration. SKU.io can only read what VeraCore exposes, and what VeraCore exposes depends on how the 3PL set your account up. Several problems on this page have no fix inside SKU.io at all — the value of diagnosing them is knowing precisely what to ask for.
Nothing is syncing at all
Start at the top of the chain rather than the symptom.
- Is the connection authenticating? Open the connection and check its status. A credential problem stops everything at once — see Connect VeraCore for what each field means and how to test it.
- Is sync switched on? The Settings → Sync section has independent toggles per data type. Inventory can be off while orders are on. See the settings reference.
- Did a job actually run? Check the job tray. A sync that was never dispatched looks exactly like a sync that failed.
- Check the Activity tab — see below. It records what the integration did and when.
If authentication is fine and syncs run but return nothing, the question becomes does this VeraCore account expose that data to the API? — which is a question for your 3PL.
Products and offers
An offer is in VeraCore but not in SKU.io. Run a catalogue sync from the Products tab. If it still does not appear, it is usually filtered out at the VeraCore end — the offer belongs to a different owner or is inactive. See Sync the offer catalogue.
An offer synced but is not mapped to a product. That is normal and expected — mapping is a separate step. Work the unmapped list on the Products tab; see Map an offer to a product.
An offer mapped to the wrong product. Automatic matching went down a rung it should not have. Remap it by hand, and if it happens repeatedly the underlying identifiers need cleaning up — usually a shared or wrong barcode.
A push to VeraCore was rejected. The two common causes are a product identifier longer than VeraCore accepts, and a field the 3PL requires that SKU.io did not send. See Push products to VeraCore for the limits and what the error text means.
Inventory numbers do not match
This is the most common report and the one where the answer is most often "they are both right".
First, read Review inventory and discrepancies. It explains what VeraCore's numbers mean, which is not what you would assume — VeraCore never reports raw on-hand, and SKU.io derives its figures from what VeraCore does report.
Then work through, in order:
| Check | Why |
|---|---|
| Is the offer mapped? | An unmapped offer's stock belongs to no SKU.io product, so of course the product shows nothing |
| Is the facility mapped to a warehouse? | Unmapped facilities have nowhere to put their stock. See Map facilities to warehouses |
| When did inventory last sync? | You may be comparing a live VeraCore screen against a SKU.io figure from this morning |
| Is stock in transit? | An announced arrival is not received stock, and does not count |
| Is there committed stock? | VeraCore reserves stock for orders it has accepted. That is a real difference, not an error |
If everything checks out and the numbers still differ, the inventory ledger shows every change SKU.io recorded and when — which usually identifies the exact movement that diverged.
Everything shows zero committed stock. That is the signature of the aggregate fallback: your VeraCore account does not have per-warehouse inventory detail enabled, so SKU.io reads the aggregate figures instead, which carry no warehouse dimension and no reservation data. Nothing is wrong in SKU.io — ask your 3PL whether inventory detail can be enabled on your account.
Orders
An order is in VeraCore but not in SKU.io. Run Refresh From VeraCore on the Orders tab. If it still does not appear after a sync, it falls outside what the connection pulls — check the date range and whether the order belongs to this connection's owner.
An order is in SKU.io but never reached VeraCore. Look at the fulfillment rather than the order. The Fulfillments tab lists what SKU.io sent; if the fulfillment is not there, it was never routed to this connection.
An order shows a None chip in the Fulfillment column. It is not linked to anything in SKU.io. That is expected for orders created directly in VeraCore, and a real problem for orders SKU.io originated — see Sync and link orders.
An order is stuck. Check its VeraCore status before assuming a sync problem. Hold and Denied Credit mean the warehouse is deliberately not shipping it, and no amount of syncing will change that.
Tracking is missing
Tracking has its own dedicated diagnosis, because it is the area where the pipeline is most visible and most often misread: Set up tracking with Dynamic Reporting.
The short version:
- Open Report Tasks and find a task covering the ship date. No task means no sync ran in that window.
- Open the task and read Where the rows went, not just the status. A Processed task can still have left rows untracked.
- Find the order in the row list and see which outcome bucket it landed in. Each bucket has its own fix.
Two failure modes are worth calling out here because they get misfiled as "tracking is broken":
The tracking number arrived but the link does not work. That is a shipping method mapping, not a tracking problem. The tracking URL comes from the mapped SKU.io shipping method; unmapped means no link.
Tracking is missing for an outage window longer than a week. The report window never looks back more than seven days, so re-running will not fill the gap. That tracking has to be chased another way.
Expected arrivals
An arrival sits in Error. VeraCore rejected the announcement. The reason is on the arrival — turn on the Last Error column, or open the arrival and read the red banner. If the reason is not specific enough to act on, the Raw VeraCore Payload panel shows exactly what was sent.
An arrival cannot be edited or cancelled. The warehouse has started receiving against it. This is not a SKU.io restriction and there is no override — see Track and cancel expected arrivals.
An arrival has no purchase order behind it. It was created directly in VeraCore. Worth investigating rather than ignoring — inbound stock with no SKU.io purchase order will not reconcile against anything when it lands.
An announcement has no lines. The warehouse has been told to expect nothing. Cancel it and re-announce from the purchase order.
Costs are not appearing
Work backwards along the chain:
- Is a Fulfillment Cost Financial Line Type configured? Without one, nothing is recorded. See Review fulfillment costs.
- Does the fulfillment carry a cost at all?
- Did the report row for that shipment have a Freight value?
If VeraCore never reported a freight figure, there is nothing for SKU.io to record, and the fix is in your 3PL's report definition.
The Activity tab
When something changed and you do not know what, the Activity tab is the first place to look. It logs every create, update, and delete on this connection's records, with who did it and when.
| Column | Notes |
|---|---|
| ID / Date / User | When, and by whom — System for anything automated |
| Event | Created, Updated, Deleted, or Bulk Upsert |
| Source | What caused it — a manual edit, a sync, an import, a webhook |
| Subject | Which record |
| Details | For updates, the actual before → after values |
Three things make it more useful than it first looks:
Settings changes are recorded field by field. When a connection setting changes, the log shows the individual key that moved and its old and new value — not an unreadable blob. So "who turned auto-push off, and when" is a question with an answer.
Bulk operations are grouped. A sync that touched four hundred records appears as one collapsible row rather than four hundred, with the event and a count. Expand it to see the individual entries.
The Source filter separates automated from human. Filtering to Manual answers "did someone change this by hand?" — often the fastest way to close a mystery.
When it is your 3PL, not SKU.io
Several problems have no fix inside SKU.io, and recognising them early saves a lot of time:
| Symptom | The ask |
|---|---|
| No committed quantities anywhere | Enable per-warehouse inventory detail on the account |
| Tracking reports fail with an unknown report name | Confirm the exact Dynamic Report name, or have it created |
| Report rows come back with no Order ID | The report definition is returning the wrong columns |
| A locked arrival needs changing | Only they can adjust it once receiving has started |
| Source codes are rejected or ignored | Get the exact accepted values, including case |
| Offers missing from the catalogue sync | Check the owner and active status on their side |
When you raise one, give them the specifics: the VeraCore order or offer id, the exact date and time, and the error text SKU.io recorded. The raw payload panels — on orders, arrivals, and report tasks — exist precisely so you can show them what was actually exchanged.
Before you escalate to SKU.io support
Have these ready and most cases resolve in one round rather than three:
- Which connection, and which tab the problem is visible on.
- The specific record — a VeraCore order id, an offer code, a report task id.
- What you expected versus what you see.
- Whether a sync has run since the change, and roughly when.
- Anything relevant from the Activity tab.
Next steps
- Settings reference — every setting, and what changing it affects.
- Connect VeraCore — credentials, and the first checks when nothing works.
- Review inventory and discrepancies — the single most useful page when numbers disagree.