Skip to main content

AirPlus DBI Field Configuration

AirPlus Descriptive Billing Information (DBI) fields are the reference data SpendOne sends with each virtual card it issues. They are what makes a card statement line reconcilable: without them a transaction arrives with an amount and a merchant and nothing tying it to a cost center or a requester.

What SpendOne sends​

Every DBI value is derived from the purchase order, not configured per card and not passed in the issuance call. POST /api/v1/credit-cards takes exactly one field, purchase_order_code; everything below is resolved from it.

ValueSource
Purchase order codeThe order the card is issued against
Purchase request codeThe request behind that order
User code, external ID, email, first and last name, phoneThe requester
Purchase request rationaleThe requester's stated reason
Amount and currencyThe order total
Supplier nameThe order's supplier
Cost center codeThe order's cost center
Project numberThe buyer-entered project number, sent as DBI field PR. Omitted entirely when empty.
Legal entityThe purchase's legal entity, which is also what resolves which AirPlus account the card bills. Not the tenant's primary entity.

Two card buckets exist. A card carrying travel details is a classic (travel) card; absent travel details it is a procurement card. The bucket selects which AirPlus DBI field set applies.

What has to exist first​

Because the values are derived, the reconciliation quality of a card is decided by the master data behind the purchase order, before any card is issued:

  1. Legal entities, with their AirPlus account configured. The account is resolved from the purchase's legal entity, so an entity without one cannot issue cards. GET /api/v1/legal-entities.
  2. Cost centers, populated and assigned. A card issued against an order with no cost center reconciles against nothing. GET /api/v1/cost-centers.
  3. Org units and users, so the requester fields resolve. See Data import via blob storage.

This is why cost centers and org units are a blocking milestone in Customer Onboarding, not a later refinement.

Re-syncing a card​

If the DBI configuration changes after a card exists:

POST /api/v1/credit-cards/sync-dbi-config
PUT  /api/v1/credit-cards/{code}

PUT /credit-cards/{code} re-syncs one card's provider and DBI data. It takes no body fields: label, owner and limit are not settable through it.

Reading transactions back​

Statement files arrive by SFTP and are announced by an internal webhook. What is exposed over them is an aggregate view and an export job, not the statement lines:

GET  /api/v1/airplus/statements/accrual-report
GET  /api/v1/transaction-events/transactions/{identifier}/events
POST /api/v1/transaction-events/export

There is no endpoint that lists ingested statement lines or card transactions. The accrual report is the month-end aggregate over them, and the export job is the supported bulk read; poll it with GET /api/v1/transaction-events/export/{job_code} and fetch the result from GET /api/v1/transaction-events/export/{job_code}/download.