> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/subscriptions/getting-started/understanding-your-import-results.md).

# Understanding your import results

Read the Import History table and the job details modal: what each counter means, why a re-upload skips everything, and how to use the failed rows download.

Every import you run is recorded in **Import History**, at the bottom of **Subscriptions → Actions → Import Subscriptions**.

<figure><img src="https://393112916-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJ8asLD4FVCFagK40xEr4%2Fuploads%2FWmkxDYI596cxq4wrgEA9%2FScreenshot%202026-09-25%20at%208.46.21%E2%80%AFAM.png?alt=media&amp;token=6cdb4df0-190e-466e-ac36-a0e2e46e0295" alt=""><figcaption></figcaption></figure>

The single most important thing about these numbers is stated above the table itself:

{% hint style="info" %}
**Rows in file** counts CSV lines. Every other column counts subscription contracts by subscription ID, not rows or customers.
{% endhint %}

That distinction matters because a contract with several products takes up several rows. A file with 26 rows can hold only 13 subscriptions. Comparing a row count against a contract count is the usual reason the numbers look wrong at first glance.

### The Import History columns

| Column            | What it counts                                                                                                      |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Job ID**        | The import's reference number. Quote it to support.                                                                 |
| **Status**        | **Completed** or **Invalid**.                                                                                       |
| **Date**          | When the import ran.                                                                                                |
| **Rows in file**  | Lines in your CSV. The only row-based figure.                                                                       |
| **Subscriptions** | Subscription contracts the import worked on, counted by subscription ID.                                            |
| **Created**       | New contracts created in Shopify.                                                                                   |
| **Updated**       | Existing contracts that were changed.                                                                               |
| **Skipped**       | Contracts deliberately left out, for example cancelled ones, or ones already present with the same details.         |
| **Errors**        | Contracts that could not be imported. Counted by subscription ID, so two bad rows for the same contract count once. |

Each heading carries an information icon with the same definition, so you can check a column without leaving the page.

**Created** and **Updated** are both counted within the **Subscriptions** figure. **Skipped** and **Errors** are reported alongside it.

### Opening a job

Click **View** on any row to open the job details.

The modal shows the job number and status at the top, then **Started**, **Completed**, and **Batches**, followed by a **Results** list of the same counters. Where products changed, the **Updated** line carries a note beneath it, for example *4 product line changes on these subscriptions*.

<figure><img src="https://393112916-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJ8asLD4FVCFagK40xEr4%2Fuploads%2FoJTyHmggdtt7gGoD1s3U%2FScreenshot%202026-09-25%20at%208.46.46%E2%80%AFAM.png?alt=media&amp;token=b2acd245-efb7-4587-b276-764372e6b38b" alt="" width="563"><figcaption></figcaption></figure>

### Failed rows

When a job has anything to report, a **Failed rows** panel appears at the bottom of the modal with a **Download CSV** button.

That file holds **rows with an error or a warning**, and each row carries its own reason. This is the only place row-level detail lives, which is deliberate: the headline counters stay at the contract level so they remain readable, and the download tells you precisely which line to fix.

<figure><img src="https://393112916-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJ8asLD4FVCFagK40xEr4%2Fuploads%2FPTbGdf68udteOXt4JjlY%2FScreenshot%202026-09-25%20at%209.20.36%E2%80%AFAM.png?alt=media&amp;token=5a4e29ee-f712-4a26-9229-bc322bcf2192" alt="" width="563"><figcaption></figcaption></figure>

A warning is not a failure. A row can appear in this file because the import changed a billing date or because a later row disagreed with an earlier one, and still have imported.

### A worked example

Three jobs run one after another show how the counters behave.

**Job 803.** A 26-row file holding 13 subscriptions, each with two product lines.

* Rows in file `26`, Subscriptions `12`, Created `11`, Updated `1`, Skipped `1`, Errors `1`
* One subscription was cancelled, so it was skipped and never counted in Subscriptions.
* Of the 12 worked on, 11 were new and 1 already existed and was updated.
* One contract could not be read and is counted once under Errors, however many of its rows were bad.

**Job 804.** The same file, uploaded again.

* Rows in file `26`, Subscriptions `12`, Created `0`, Updated `0`, Skipped `13`, Errors `1`
* Nothing was created, because everything was already there from job 803. Those 12 duplicates plus the cancelled contract make up the 13 skipped.
* Because the job created and updated nothing, its status reads **Invalid** rather than Completed. The file was fine. There was simply nothing left to do.

**Job 805.** A 6-row file holding 4 subscriptions, run with the products option on.

* Rows in file `6`, Subscriptions `4`, Created `0`, Updated `4`, Skipped `0`, Errors `1`
* All four already existed, so all four were updated rather than created, with `4 product line changes on these subscriptions` noted under Updated.

### What to check when the numbers surprise you

* **Subscriptions is lower than Rows in file.** Expected. Multi-product contracts span multiple rows.
* **Everything was skipped.** The contracts are already in Shopify with the same details, or they are all cancelled contracts. Re-running an import is safe and will not duplicate anything.
* **Errors is lower than the number of bad rows you can see in the download.** Expected. The Errors column counts the number of unique subscription contract ids, the download column counts the number of rows.
* **A contract imported but kept its old payment method.** The payment method could not be migrated. The contract is fine and the reason is reported against it.

For a large migration, run **Actions → Verify Import** afterwards. It compares your CSV against what is now live in Shopify, reports any mismatches, flags subscriptions that ended up with two live contracts that could both bill, and shows the reason the import refused anything it would not apply.

### Related guides

* [Import subscriptions from a CSV](/subscriptions/getting-started/import-subscriptions-from-a-csv.md)
* [Filtering the subscriptions list](/subscriptions/managing-subscriptions/filtering-the-subscriptions-list.md)
* [The Subscription Activity Timeline](/subscriptions/managing-subscriptions/the-subscription-activity-timeline.md)
* [Marking a subscription as failed](/subscriptions/managing-subscriptions/marking-a-subscription-as-failed.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.roadmap.so/subscriptions/getting-started/understanding-your-import-results.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.