The Rate Revision That Hit Last Year's Costs

The decision point. Burdening happens during cost distribution, and the version is selected by matching the expenditure item date of the transaction against the version's effective date range. The Distribute Costs run does not let you pick a version, and it does not use the run date or the GL date. That single fact explains the whole symptom: if a December service item were genuinely dated in December, it would have found the version that ended 31 December 2025. It found the 2026 version, so the application believes the item is dated in 2026.

Plausible causes, in order of likelihood:

1. The cost interface or time-card import defaulted the expenditure item date to the current date (or to the load date) instead of the service date. This is the classic version of this incident.
2. The source document carried the wrong transaction date (a period-end time card submitted late with January dates).
3. The expenditure item date was derived from the GL accounting date of the source transaction rather than the service period.
4. The prior version's end date or the new version's start date was keyed incorrectly, so the ranges diverge or overlap earlier than intended.

Verification: query a sample of the 380 items and compare expenditure item date, transaction date and GL date, then read the burden lines' schedule and version. If the item dates are January but the services were December, cause 1 or 3 is confirmed.

Correction path: re-running distribution will not re-burden items that are already distributed, so the fix is to reverse the affected burden and cost through the cost adjustment process, correct the expenditure item dates in the source interface, re-import, and redistribute. Do not simply accept the 2026 rates on December work; that misstates the period and the audit trail.

Distribution is designed to be safe to re-run: it selects unprocessed expenditure items and skips items already processed. Therefore a second set of burden lines for the 62 items means a second set of expenditure items, not a second burdening of the same items. The usual explanations are:

• The same source transactions were imported twice (interface re-run without a duplicate check, or a changed interface key), creating two expenditure items pointing at the same source document.
• December distributions were reversed and redistributed while the original lines were not fully reversed, leaving both sets live.
• Two different sources (time cards and a manual cost import) captured the same labour.

Triage: compare the interface's source identifier, employee, date and amount across the duplicated pairs, and confirm whether both items have the same source document number. That immediately separates a double import from an incomplete reversal.

Correction: reverse the duplicate burden and cost with the cost adjustment process so the audit trail shows the reversal and the reason, rather than deleting anything.

Prevention controls:

1. Run the cost import once per period per source and reconcile interface record counts to source counts before distribution.
2. Configure duplicate detection on the interface key (source document plus line plus date) so a replay is rejected rather than imported.
3. Schedule distribution with explicit project and date range parameters, and review the count of items selected against the expected unprocessed volume each period.
4. Put into the close checklist: any reversal that will be redistributed must be fully processed before the next distribution run.

Precedence controls the order in which burden schedules are applied - lowest precedence number first - so Fringe lands before Overhead, and Overhead before G&A. Order matters only because each subsequent schedule may be applied to cost that already carries the earlier burdens.

The two distinct effects in this incident:

• Rate effect: 380 December items carried 2026 rates instead of 2025 rates. That alone moves the December total.
• Compounding effect: G&A at precedence 30 is applied to cost that already includes Fringe and Overhead. So the total is base x (1 + Fringe) x (1 + Overhead) x (1 + G&A), not base + Fringe + Overhead + G&A. The difference grows with the size of the indirect rates, and it is often where an unexplained percentage overstatement comes from when someone re-tests the numbers with the additive formula.

Proving one item: pull a single December item's base cost and burden lines, then recompute the chain in precedence order using the version that should have applied (December-dated), comparing against the version that did apply. If the recomputed figure with additive logic matches the ledger, the burden structure is not compounding - check the burden cost codes and whether burden is being allowed on burden where policy says it should not be. If the multiplicative figure matches, the structure is compounding as designed and the variance is purely the rate effect plus the duplicate lines.

Also check: that duplicating burden lines from the 62 items are not being counted twice in the 6.8 percent, and that precedence changes are not being made mid-period - reordering schedules changes every downstream amount and is not retroactively recalculated for items already distributed. Reconcile the month in three layers: base cost, rate variance, duplicate variance; if those three do not explain the total, examine precedence changes made during the period.