Posting a back-dated inventory adjustment

When you enter an inventory adjustment for stock that moved on an earlier date, you can now supply a business date so the ledger records the event in the period it actually occurred — not the period you entered it.

What this affects

  • The 'Posted Date' shown in the adjustment detail and in inventory drill-down reports
  • Which accounting period the quantity change is counted toward in the stock snapshot and other aggregated reports

Without a business date the adjustment behaves exactly as before: it is filed under the date and time you save it.

Via the External API

Add the effective_date field to your adjustment payload at creation time:

POST /v1/api/external/inventory/adjustments
{
  "effective_date": "2026-07-28",
  "remarks": "July count correction entered in August",
  "adjustment_entries": [
    { "warehouse_id": 12, "rfq_id": 456, "qty_onhand": -3, "adjusted_uom_id": 7 }
  ]
}

effective_date accepts any valid date or datetime string. The system normalises the value so the calendar day is the same in both the display label and the ledger row, even across timezone boundaries.

Accepted at create only. Once an adjustment is posted the business date cannot be changed in place. If you supplied the wrong date, delete the adjustment and re-post it with the correct one. (The delete endpoint reverses all inventory movements automatically.)

Important: null effective_date = today (legacy behaviour preserved)

If you omit effective_date or pass null, the adjustment is treated exactly as it was before this change — the ledger row is dated to the time of posting. No existing integrations are affected.

Period-lock interaction

If the effective_date you supply falls inside a closed accounting period, the adjustment will be refused with a 422 response naming the period that is closed and the date you attempted. Re-post with a date that falls in an open period, or ask your administrator to open the relevant period first.

Correcting a wrong business date after posting

Because the date is frozen into the ledger rows at post time, it cannot be patched without mutating historical records. The supported correction path today is:

  1. Delete the adjustment (reverses all inventory movements).
  2. Re-post it with the correct effective_date.

A future update will make the date correctable in place.