# Data import examples

Learn how to apply data import to common use cases.

## Adding a service period to a Stripe payment 

In this example, you use Stripe as a payment processor, but have your own recurring payment solution. You have payments in Stripe, but your separate system keeps the service period for these payments.

Suppose you have a payment in Stripe with the ID `py_1234` of 120 USD on January 1, 2025 that represents a yearly *subscription* (A Subscription represents the product details associated with the plan that your customer subscribes to. Allows you to charge the customer on a recurring basis) from February 1, 2025 to January 31, 2026. To add this data to Stripe, you can import a CSV with the following fields:

| source | transaction_id | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description |
| ------ | -------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | ----------- |
| Stripe | py_1234        |                      |             | 2025-02-01             | 2026-01-31           |        |          |             |

Stripe already has data on the booked date, amount, and currency, so you can leave these fields blank.

## Adding or overriding a service period on an invoice line item 

In this example, you use [Stripe Invoicing](https://docs.stripe.com/invoicing.md), but you have your own recurring payment solution. You may have missing or incorrect service periods on your *invoice* (Invoices are statements of amounts owed by a customer. They track the status of payments from draft through paid or otherwise finalized. Subscriptions automatically generate invoices, or you can manually create a one-off invoice) line items.

Say you manually generated an invoice for a large enterprise customer and finalized this invoice on April 1, 2025. The invoice has the ID `in_1234` and has several line items, some of which are physical goods, and some of which are subscriptions for other products. In your [revenue recognition report by line item](https://docs.stripe.com/revenue-recognition/reports.md#statements), you notice:

- An unexpected increase in April revenue in your report. The line item for one subscription (`il_5678`) has no service period, and so all of the revenue for that line item books into April.
- Another line item for another subscription (`il_7890`) has an incorrect service period of April 1, 2025 to April 15, 2025, resulting in revenue recognized in April.

You want to recognize revenue for `il_5678` from May 1, 2025 to June 1, 2025, and recognize the revenue for `il_7890` from June 1, 2025 to September 1, 2025.

| source | transaction_id | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description |
| ------ | -------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | ----------- |
| Stripe | in_1234        | il_5678              |             | 2025-05-01             | 2025-06-01           |        |          |             |
| Stripe | in_1234        | il_7890              |             | 2025-06-01             | 2025-09-01           |        |          |             |

Stripe already has data on the booked date from the invoice finalization date, amount, and currency, so you can leave these fields blank.

## Splitting Stripe payments with additional data 

In this example, you use Stripe as your payment processor. You have payments in Stripe, but these payments may represent multiple different goods and services that you want to have custom revenue recognition schedules for.

Suppose you have a payment in Stripe of 100 USD with the ID `py_1234` that represents two separate goods and services:

- A 74.99 USD subscription recognized from February 1, 2025 to May 31, 2025.
- A 25.01 USD shipment of materials recognized immediately on a shipment date of January 1, 2025.

To split this Stripe payment, you could provide the following data:

| source | transaction_id | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description                               |
| ------ | -------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | ----------------------------------------- |
| Stripe | py_1234        | subscription         |             | 2025-02-01             | 2025-05-31           | 74.99  | USD      | The subscription part of the payment      |
| Stripe | py_1234        | shipment             |             | 2025-01-01             | 2025-01-01           | 25.01  | USD      | The material shipment part of the payment |

You must specify a unique **Split transaction ID** for each part of the transactions. This helps us differentiate different parts of a payment with the same ID. The only requirement is that each **Split transaction ID** is unique.

Stripe already has data on the booked date and currency, so you can leave these fields blank, or fill them in with the correct values. We’ll check that the amounts of each component of the payment add up to the original payment amount, and that the currencies (if specified) stay the same. The descriptions are optional.

## Importing external transactions 

In this example, you’re migrating to Stripe from a different payment processor or have a multiple payment processor solution.

Suppose you’re migrating your subscriptions to Stripe, and all of them have already been paid for. One of these subscriptions is a yearly subscription from January 1, 2025 to December 31, 2025 paid for in advance on December 15, 2024 for a price of 100 USD. To import this data into Stripe for revenue recognition purposes, you can provide the following data:

| source             | transaction_id   | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description           |
| ------------------ | ---------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | --------------------- |
| My previous system | Transaction 1234 |                      | 2024-12-15  | 2025-01-01             | 2025-12-31           | 100    | USD      | A yearly subscription |

Because Stripe doesn’t have any data on this transaction, you must provide every field except **Split transaction ID** and the always optional **Description**. You can also provide a **Split transaction ID** if that best represents your data.

The currency must be a [currency supported on your account](https://docs.stripe.com/currencies.md) in Stripe, but otherwise the data in any of the other fields has no restrictions.

## Correcting imported data 

If you make a mistake when importing data, you can [delete the transaction in the Dashboard](https://docs.stripe.com/revenue-recognition/data-import/manage-imported-data.md#transactions-deletion), and re-import the correct data to correct the errors. Alternatively, you can upload a new CSV, and any rows with the corresponding **Source**, **Transaction ID**, and **Split transaction ID** to replace the old imported data.

Suppose you have an import like the one below, but want to remove the recognition start and end dates and change the booked date to March 1, 2026.

| source | transaction_id | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description |
| ------ | -------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | ----------- |
| Stripe | py_1234        |                      |             | 2025-02-01             | 2026-01-31           |        |          |             |

You can import another CSV with the following format, and it completely replaces the previous row:

| source | transaction_id | split_transaction_id | booked_date | recognition_start_date | recognition_end_date | amount | currency | description |
| ------ | -------------- | -------------------- | ----------- | ---------------------- | -------------------- | ------ | -------- | ----------- |
| Stripe | py_1234        |                      | 2026-03-01  |                        |                      |        |          |             |

The blank fields for **Recognition start date** and **Recognition end date** signal that we use the recognition start and end dates for the existing payment, `py_1234`. The previous incorrect recognition start and end date for the import are no longer used.

## Excluding transactions from revenue  

You might want to exclude certain transactions from your revenue recognition process because they were erroneously generated due to incorrect settings or are test transactions.

For example, you have five transactions to exclude from your revenue:

- in_1234 – test invoice
- ii_1234 – invoice item incorrectly generated from a subscription update
- in_5678 – invoice that includes multiple line items, of which il_1234 was mistakenly added
- py_1234 – standalone payment created by a problematic integration
- ch_1234 – test standalone charge

To exclude these transactions, [download the CSV template for Exclusion Import](https://dashboard.stripe.com/revenue-recognition/data-import) and fill in the IDs as follows:

| transaction_id |
| -------------- |
| in_1234        |
| ii_1234        |
| il_1234        |
| py_1234        |
| ch_1234        |

## Import journal entries  

You might want to import a journal entry to offset any current data and make adjustments to your reporting. For example, you have an invoice with the ID `in_1234`. You want to credit 0.03 USD of AccountsReceivable against OtherLoss in the 2026-07-01 accounting period.

To offset this journal entry, [download the CSV template for Journal Entry Import](https://dashboard.stripe.com/revenue-recognition/data-import) and fill in the IDs as follows:

| accounting_period_date | debit_account | credit_account     | settlement_amount | settlement_currency | transaction_id | debit_account_gl_name | credit_account_gl_name | debit_account_gl_code | credit_account_gl_code | presentment_amount | presentment_currency | description |
| ---------------------- | ------------- | ------------------ | ----------------- | ------------------- | -------------- | --------------------- | ---------------------- | --------------------- | ---------------------- | ------------------ | -------------------- | ----------- |
| 2026-07-01             | OtherLoss     | AccountsReceivable | 0.03              | USD                 | in_1234        |                       |                        |                       |                        |                    |                      |             |