> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pleo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Fetch Export Item Data

export const RememberCallout = ({title, children, icon = "🪢"}) => <div style={{
  backgroundColor: 'var(--recommended-bg)',
  borderLeft: '4px solid #f63b92',
  borderRadius: '10px',
  padding: '18px 22px',
  marginBottom: '20px',
  boxShadow: '1px 1px 3px rgba(0,0,0,0.06)'
}}>
    <div style={{
  display: 'flex',
  alignItems: 'flex-start',
  gap: '14px'
}}>
      <span style={{
  fontSize: '22px',
  lineHeight: '1',
  flexShrink: 0
}}>
        {icon}
      </span>
      <div>
        {title && <div style={{
  fontSize: '16px',
  fontWeight: 600,
  color: 'var(--recommended-title)',
  marginBottom: '6px'
}}>
            {title}
          </div>}
        <div style={{
  fontSize: '14px',
  lineHeight: 1.65
}}>
          {children}
        </div>
      </div>
    </div>
  </div>;

This page describes how integrations retrieve **full Export Item data** after determining which items require processing.

Export Item data represents the **data layer** of the export workflow. It contains the complete accounting payload required to create entries in the target Accounting System.

## Implementation

See the corresponding how-to article for API usage and step-by-step instructions:

* [How to Fetch Export Item Data for Processing](/docs/current/how-tos/accounting-integrations/how-to-fetch-export-item-data-for-as-erp-processing)

## Purpose

* Retrieve full accounting data for Export Items
* Provide all fields required for processing and mapping
* Ensure consistent and complete payloads for downstream workflows

## Control Layer vs Data Layer

Export processing is split into two distinct responsibilities:

| Layer                  | Responsibility                   |
| ---------------------- | -------------------------------- |
| Control Layer          | Identify items and track status  |
| Data Layer (this step) | Retrieve full accounting payload |

This step operates **only on data retrieval**.

## Fetching Export Item Data

Use the **Export Items** endpoint with the `jobId` of the in-progress Export Job.

```http theme={null}
GET /v3/export-items?job_id={jobId}
```

## Data Returned

Each Export Item includes all information required for processing, including:

### Core Transaction Data

* transaction type and subtype
* transaction date
* notes and metadata

### Amounts

* supplier currency
* wallet currency
* net and gross values

### Accounting Entry Lines

* GL account information
* tax codes and rates
* line-level amounts

### Supplier / Vendor Data

* supplier details (name, country, category)
* vendor details (IDs, external references)

### Organisational Context

* user
* team
* cost allocation metadata

### Attachments

* file URLs
* file types and sizes

### Bookkeeping Metadata

* bookkeeping method (e.g. journal, payable)
* additional accounting attributes

## Processing Model

Export Item data is returned as a collection.

Each item must be processed **individually**.

```pseudo theme={null}
items = fetchExportItems(jobId)

for item in items:
    process(item)
```

The integration is responsible for applying accounting logic to each item.

## Pagination

Export Items may be returned across multiple pages.

Integrations must retrieve **all pages** before beginning processing.

### Example Pagination Response

```json theme={null}
{
  "pagination": {
    "hasNextPage": true,
    "endCursor": "<cursor>"
  }
}
```

### Example Pseudo

```pseudo theme={null}
items = []

do:
    response = fetchItems(cursor)
    items.append(response.data)
    cursor = response.pagination.endCursor
while response.pagination.hasNextPage
```

<RememberCallout title="Remember">
  Processing incomplete datasets may result in missing accounting entries and inconsistent exports.
</RememberCallout>

### Before Processing: Validate Each Item

Before beginning downstream processing, run two quick checks on each item and immediately mark any that fail. This avoids attempting to record items in your AS that are guaranteed to fail.

For each item check:

1. **Required configurations are present**: the journal is configured and required accounts are mapped for this item
2. **Expense GL Account (Category) is present**: `accountingEntryLines[].account` is populated.

If either check fails, mark the item as `failed` with `failureReasonType: "missing_configuration"` and skip it. Items that pass both checks are ready for processing.

See [How to Update Export Items](/docs/current/how-tos/accounting-integrations/how-to-update-export-items-for-as-erp-processing) for how to report failed items back to Pleo.

## Consistency Guarantees

Export Item data is tied to a specific Export Job.

* Data reflects the state at the time the job was created
* Items within a job should be treated as a consistent batch
* Re-fetching data during recovery should return the same logical dataset

## Relationship to Control Layer

This step must follow the control layer:

1. Retrieve Export Job Items (control layer)
2. Identify items to process (e.g. `pending`)
3. Fetch full Export Item data (this step)

The integration may choose to:

* fetch all data upfront, or
* fetch and process incrementally

## Resumability & Recovery

If the integration restarts:

* Re-fetch Export Item data using the same `jobId`
* Use control layer state to determine which items still require processing

This ensures:

* idempotent processing
* safe retries
* consistent outputs

## Idempotency Considerations

To ensure safe retries:

* Use `accountingEntryId` as the unique identifier
* Avoid duplicate entry creation in the Accounting System
* Coordinate with control layer status tracking

## Expected Outcome

After completing this step:

* Full accounting payloads for all Export Items have been retrieved
* Pagination has been resolved
* Data is ready for processing in the Accounting System
* The workflow remains resumable and consistent

## Upstream Dependencies

* Export Job Items retrieved (control layer)
* Items to process identified (e.g. `pending`)
* Export Job is `in_progress`

## Downstream Dependencies

* AS/ERP processing workflow
* Export Item status updates
* Export Job completion

***

## What Comes Next?

* [Determine Bookkeeping Method](/docs/current/integration-design/exports/integration-design-exports-bookkeeping-method-resolution)

***

## Related Reading

* [How to Fetch Export Item Data for Processing](/docs/current/how-tos/accounting-integrations/how-to-fetch-export-item-data-for-as-erp-processing)
* [Export Integration Workflow Guide](/docs/current/guides/export-integration-workflow-guide)
* [AS/ERP Processing Workflow Guide](/docs/current/guides/accounting-system-processing-workflow-guide)

***

## FAQs

<Accordion title="Why am I getting a MISSING_CONTRA_ACCOUNTS error?">
  You're getting a `MISSING_CONTRA_ACCOUNTS` error, because the Export API v3 requires a contra account to be configured for each entity's default currency. If any entity's default currency does not have a contra account mapped, calls to `/v3/export-items` will fail with this error.

  See [How to Resolve MISSING\_CONTRA\_ACCOUNTS](/docs/current/how-tos/accounting-integrations/how-to-resolve-missing-contra-accounts) for steps to fix this.
</Accordion>

<Accordion title="Why is the `bookkeeping` field returning `null` in my export items response?">
  You're getting a `null` value for the `bookkeeping` field, because it's only populated when the **Vendor Tagging** feature is enabled and a bookkeeping method has been assigned to the expense before it was queued. Without Vendor Tagging enabled, `bookkeeping` will always be `null`. This is expected behaviour, not an error.

  When `bookkeeping` is `null`, use the `supplier` field on the export item for bookkeeping purposes instead.

  See [How to Enable Vendor-Based Bookkeeping](/docs/current/how-tos/accounting-integrations/how-to-enable-vendor-based-bookkeeping) for steps to enable it.
</Accordion>

***