SaaS billing dates disappeared after an integration upgrade: check the item records

When billing-period dates become blank or unexpectedly identical after an integration update, ask the system owner which source fields and API version the export uses. Preserve a recent successful export and an affected one. Compare the raw source records with the transformation before correcting dates manually in the accounting spreadsheet.

Stripe's March 2025 Basil change moved current billing-period fields from the subscription level to subscription items. An integration using the older shared fields needs review when adopting that version. Confirm the version actually used by your account and integration; a published platform change does not prove that every account has already adopted it.

List the item identifier, product, price, quantity and period start and end used in the export. Keep invoice-line references where they are relevant to the accounting schedule. If the transformation produces one row per subscription, establish how it handles multiple items instead of simply taking the first date encountered.

Ask finance what the downstream report requires. A renewal calendar may need the next event for each item, while a revenue workpaper needs the service evidence appropriate to each promise. A single convenient subscription date can be insufficient for either purpose when the underlying items have different periods or amendments.

Select subscriptions with one item, multiple items, a recent addition, a canceled item and an amended period where those cases exist. Compare the source, export and resulting report for each. Record expected row counts as well as values; dropping an item can leave a plausible total if another step aggregates or fills missing data.

For an illustrative account containing a base service and a later-added service, the two item records may need separate date handling under the actual arrangement. The test should establish which dates belong to which line. It should not copy the base service's period onto every item merely because the old export expected one shared field.

Identify the first affected extraction date and the reports that used the changed data. Recalculate the relevant schedules from corrected fields, keeping other inputs constant. Quantify differences in period allocation, renewal timing and missing lines. Have accounting assess any required correction under the business's reporting process.

Retain the original exports and identify any manual date fills made while the issue was being investigated. Replace them through a controlled correction with source evidence. Otherwise an automatic import can appear fixed while earlier workbooks continue carrying assumptions that no longer match the underlying subscription history.

Give the engineering owner a small set of representative records and expected financial outputs for future changes. Include field presence, item completeness, date relationships and total reconciliation. These checks should verify the information finance relies on, not merely that an API request returns successfully.

Document the approved mapping and the owner responsible for monitoring platform changes. Keep the version and extraction timestamp with important close exports. The resulting handoff lets finance recognize a source-data change early and gives engineering a concrete acceptance standard for the accounting reports that depend on it.