The audit trail in Ordovee — who changed what, when, why

“You shipped 1, I ordered 2.”

A customer emails the shop. Their package arrived, they opened it, and they’re short a part. The carrier can’t help — the box left the warehouse days ago. Now the question is yours to answer: did the pick go wrong, or did the full quantity ship?

You can’t time-travel to watch the picker work. What you can do is walk backwards through the records of what actually happened — who picked the order, what they confirmed, what the bin counts were at the time, and what they are right now. Put those pieces together and the answer is usually clear. Either there’s a mis-pick to make right, or you have the evidence to back up “the full quantity shipped.”

That reconstruction is what Ordovee’s audit trail is designed for.

One system, three layers

Ordovee records what happens in your operation across three complementary streams. Each layer answers a different kind of question:

• The change log — who edited this record? (a SKU, a price, a location code, an order status)
• The inventory ledger — who moved this stock? (every add, remove, transfer, and adjustment)
• The activity record — what did the automated systems do? (every import, marketplace sync, and run)

You rarely need all three at once. But when something looks off — a count that shouldn’t have drifted, a SKU that changed without warning, a push that didn’t go through — knowing which layer to look at is how you get to the answer fast.

Layer 1: the change log

What does the change log record? Any time someone edits a record in Ordovee, it captures the field, the old value, the new value, the user who made the change, and the timestamp. This covers item attributes (SKU, description, price, weight), location codes, order status changes, user roles, and company settings.

The value here is in the diff. You don’t just see “this record was edited on Tuesday.” You see that the SKU field changed from BRK-4891-A to BRK-4891-B, that Patrick made the change at 2:47 PM, and whether anything else was touched in the same edit. A month later, when someone asks “why is this part’s SKU different from the eBay listing?” the change log has the answer with a timestamp and a name attached.

This layer is where accountability for configuration drift lives. It catches the small edits that quietly break downstream behavior — a SKU edit that breaks a marketplace match, a location code change that orphans a bin, a role change that gave someone access they shouldn’t have had.

Layer 2: the inventory ledger

The second layer is the inventory ledger — every stock movement recorded as its own entry, in the order it happened, with full attribution. Adds, removes, transfers, and adjustments each become a permanent row in the ledger, and that ledger is the system of record for every quantity in your operation.

This is the layer that answers “when did this bin drop from 8 to 5, and under what actions?” It’s a deep enough topic that it has its own guide — How Ledger-Based Inventory Is Used in Ordovee — so we won’t retread the mechanics here. What matters for the audit trail is that the ledger and the change log are linked: if a ledger entry references an order, you can jump from that entry to the order record and see the change log for the order itself. The same works for transfers, imports, and marketplace syncs.

Layer 3: activity records

The third layer records what the automation engine did. Every run produces an activity record: when it started, when it ended, what it touched, and whether it succeeded, failed, or ended with work still remaining.

If the eBay quantity push was supposed to run after a sale, there’s a row for it. If a CSV import processed 847 rows and flagged 12, that’s a row with the counts. If a nightly reconciliation found a drift between Ordovee and Shopify, that’s a row with the diff.

The activity record is the layer that answers “is the system doing what I think it’s doing?” When automation is working cleanly, you don’t need to look at it. When something feels off — inventory isn’t pushing, orders aren’t importing, a run seems stalled — the activity record is where the diagnosis starts.

Source tags: person, import, or engine

Every entry across all three layers carries a source tag — a short marker that identifies what kind of actor produced the change. This is how you tell a person’s click apart from a CSV import apart from a run, even when the entries sit next to each other in the same record’s history.

A few examples of what you’ll see:

• A direct edit — a person changed the record right in the app.
• A bulk import — the change came in through a CSV import.
• Order processing — the change came from a pick, pack, or ship.
• An eBay sync — the change came from a marketplace sync.
• A stock move — a stock movement, tagged to the operator who performed it.

Source tags let you answer questions like: “Did a person touch this SKU, or was the change from an import?” “When did the automation engine last update this quantity?” “Did any of yesterday’s count adjustments come from a single user, or from multiple sessions?” The tag doesn’t replace the user attribution — you still see who — it just tells you whether the who was acting directly, running an import, or supervising an automated process.

Walking the opening scenario

Back to the customer who says they received 1 of the 2 parts they ordered. Here’s what the three layers look like when you open the order:

The order’s change log shows the order was created by the eBay sync at 9:47 AM, status moved from “new” → “allocated” at 9:47 AM, and “allocated” → “picked” at 10:12 AM by Maria.

The inventory ledger shows a REMOVE of quantity 2 from bin B-04 at 10:12 AM, actor Maria, source order processing, tied to the order’s reference ID.

The activity record shows the packing slip generated at 10:15 AM, and the marketplace quantity push completed at 10:17 AM.

The current bin count at B-04 is what you expected it to be based on the ledger.

Read together, the evidence supports “2 units left the warehouse for this order.” That’s something you can send to the customer with confidence, and something you can point to if the dispute escalates.

Now flip the scenario: the current bin count at B-04 is one higher than the ledger expects. That’s a signal in the other direction — a likely mis-pick where only 1 unit actually left the bin. The audit trail doesn’t tell you which of the two happened for certain, but it tells you which possibility the evidence points at, and what to check next.

See how a specific order’s audit trail comes together → Walk through the order lifecycle in Ordovee

Where this shows up in day-to-day operations

The customer-dispute case is the obvious one, but the audit trail earns its keep in smaller, quieter ways every week:

• Bin drift investigations. A cycle count shows B-07 is off by 3. The ledger tells you when it drifted and under what actions — and the change log tells you whether anyone edited the location code or the item’s SKU in the same window.
• Training checks. A new warehouse hire processed 12 returns yesterday. You can see each one as an ADD entry in the ledger with their name, timestamp, and reason — and spot-check a few to make sure the process is clean before volume picks up.
• Automation sanity. The Shopify quantity push is supposed to run within minutes of a sale. The activity record tells you whether it actually fired, or whether there’s a gap you need to look into.
• Configuration history. Six weeks ago someone changed the default fulfillment location for a set of SKUs. Today you’re wondering why those items keep getting picked from the wrong bin. The change log has the edit, the user, and the date.

In each of these, the common thread is the same: the record of what happened is already there, already attributed, already searchable. You don’t have to reconstruct it from memory or piece it together from Slack messages.

What you get

Over time, every shop accumulates questions about what happened — small ones about individual parts, bigger ones about trends and drift. Ordovee’s three audit layers are designed so those questions have answers that sit in the app, waiting to be pulled up.

Consistent records. Full attribution. Source tags that tell you who or what was acting. It’s the layer that makes your other records trustworthy — and it runs quietly in the background whether anyone’s looking or not.

→ See how this fits with the rest of inventory: How Ledger-Based Inventory Is Used in Ordovee → Ready to see your own shop’s audit trail in action? Trace a Change in ODV | See the Full Feature Set