Accounts Payable Handling

When bookkeeping.method is accounts_payable, Export Items must be recorded using Accounts Payable bookkeeping. Accounts Payable bookkeeping separates vendor liability (invoice) from vendor settlement (payment). These events may occur at different times and may originate from different Export Jobs. This page defines how integrations must construct invoice entries, payment entries, and reconciliation behaviour once the resolved bookkeeping method for an Export Item is accounts_payable.

Implementation

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

How to Determine the Bookkeeping Method

Processing Model

Accounts Payable handling follows this processing order:

Vendor Resolution
Invoice and Payment Recording
Expense Type Handling
Reconciliation
Special Cases

Each Export Item must pass through these steps during processing.

Example Export Item Payload (Accounts Payable)

{
  "data": [
    # [other Export Items omitted for brevity]
    {
      "companyId": "12abc3d4-e567-890e-1234-abc56e78fabc",
      "accountingEntryId": "98441fe2-6d31-4d52-8569-687de8368cb2",
      "type": "invoice",
      "subType": null,
      "date": "2025-04-18T00:00:00Z",
      "amount": {
        "inSupplierCurrency": {
          "currency": "GBP",
          "value": 130000
        },
        "inWalletCurrency": {
          "currency": "GBP",
          "value": 130000
        }
      },
      "note": "This was approved before the event.",
      "files": [
        {
          "url": "https://pleo-invoices.../12abc3d4-e567-890e-1234-abc56e78fabc/CR4VBJ7UUGK00/original.pdf..."
        }
      ],
      "supplier": {
        "code": null,
        "name": "TestSupplier123",
        "categoryCode": null,
        "country": "GB",
        "account": null,
        "taxIdentifier": "12345"
      },
      "user": {
        "id": "f1b5d950-1dbd-4493-8e8c-59fcfe13964f",
        "name": "Natalie White",
        "code": null
      },
      "team": null,
      "accountingEntryLines": [
        {
          "accountingEntryLineId": "98441fe2-6d31-4d52-8569-687de8368cb2",
          "lineAmount": {
            "inSupplierCurrency": {
              "currency": "GBP",
              "value": 130000
            },
            "inWalletCurrency": {
              "currency": "GBP",
              "value": 130000
            }
          },
          "netAmount": {
            "inSupplierCurrency": {
              "currency": "GBP",
              "value": 108333
            },
            "inWalletCurrency": {
              "currency": "GBP",
              "value": 108333
            }
          },
          "account": {
            "id": "eef29cf3-c6aa-45a8-b316-ae5b61d3a497",
            "code": "4650000",
            "name": "Marketing",
            "identifier": "4650000"
          },
          "tax": {
            "id": "b7440cfa-080e-42f2-a267-feb065ac98c9",
            "code": "0002",
            "type": "inclusive",
            "amount": {
              "inSupplierCurrency": {
                "currency": "GBP",
                "value": 21667
              },
              "inWalletCurrency": {
                "currency": "GBP",
                "value": 21667
              }
            },
            "rate": 0.20
          },
          "tags": [
            {
              "id": "4818af60-c790-4208-930a-87db98108193",
              "groupCode": "Project A",
              "code": "004"
            }
          ]
        }
      ],
      "additionalInformation": {
        "reconciliationId": "0",
        "reconciledEntries": null,
        "attendees": [],
        "invoiceInformation": {
          "invoiceNumber": "WZM259435",
          "status": "ready",
          "invoiceDate": "2025-04-18T00:00:00Z",
          "dueDate": "2025-04-30T00:00:00Z",
          "paymentDate": null,
          "supplierBankAccount": {
            "bankName": "NATIONAL WESTMINSTER BANK PLC",
            "bankCode": "123456",
            "accountNumber": "09876543",
            "country": "GB",
            "bic": null,
            "iban": null
          }
        }
      },
      "bookkeeping": {
        "method": "accounts_payable"
      },
      "vendor": {
        "id": "22e1f2c9-1360-4291-ab41-6b23dcea8888",
        "name": "TestVendor",
        "code": "acc1234",
        "externalId": "ext12345",
        "registrationNumber": "reg001234",
        "taxRegistrationNumber": "taxreg1234",
        "country": "UK",
        "defaultCurrency": "GBP"
      },
      "contraAccount": null,
      "_links": {
        "web": {
          "exportItem": "https://app.staging.pleo.io/export/export-item/98441fe2-6d31-4d52-8569-687de8368cb2"
        }
      },
      "servicePeriod": {
        "from": "2025-04-18T00:00:00Z",
        "to": "2025-04-18T00:00:00Z"
      }
    }
  ],
  "pagination": {
    "hasPreviousPage": false,
    "hasNextPage": false,
    "currentRequestPagination": {
      "sortingKeys": [],
      "sortingOrder": [],
      "parameters": {
        "job_id": [
          "c62931c9-ecd4-4a6f-9f43-f759ac297707"
        ]
      }
    },
    "startCursor": "AAAAAADJ5MVAOIR2ZFYA=ZOA73ZCZDVDJNGJSQHCX2LCGPY",
    "endCursor": "AAAAAADJ5MVAOIRZQFIA=GBA43XWBQRCCLFTOWOQKVJUAUU",
    "total": 4
  }
}

1. Vendor Resolution

Detection

bookkeeping.method = accounts_payable

Rule

A vendor must be resolved before creating invoice entries. The integration must attempt vendor matching using the following priority order:

vendor.code
vendor.account
vendor.taxIdentifier

If a vendor object exists, the supplier object must be ignored.

Failure Behaviour

If vendor matching fails:

The Export Item must not be recorded
The Export Item must fail in Pleo

Failure reporting:

failureReasonType
- vendor_unknown (Export V3)
- accounting_system_validation_failure (Export V2)
failureReasonMessage Selected vendor cannot be processed because it does not exist or is currently blocked. Please verify the vendor’s status in the accounting system and try again.

Legacy Support

If no bookkeeping object is present but a supplier object exists, attempt vendor resolution using the supplier object’s identifiers. Use the following priority order to find a matching vendor in your AS:

Priority	Supplier Field	Match Against in AS
1	`supplier.code`	Vendor ID
2	`supplier.account`	Vendor account number
3	`supplier.taxIdentifier`	Vendor tax identifier or tax registration number

Work through each field in order, stopping as soon as a match is found. If no match is found after all three, fail the Export Item using the same failure behaviour as standard vendor resolution.

2. Invoice and Payment Model

Detection

bookkeeping.method = accounts_payable

Rule

The integration must record:

Vendor liability as an invoice object
Vendor settlement as a payment entry

Payment recording may occur by:

Marking the invoice as paid, and/or
Creating a separate payment entry

Implementation depends on Accounting System capabilities.

Behaviour Notes

Invoice and payment entries may be recorded at different times and may originate from separate Export Jobs.

3. Expense Type Handling

Detection

After vendor resolution succeeds.

Rule

Export Item type determines whether an invoice, payment, or both must be recorded.

card_invoice, card_purchase, fee

Record an invoice entry
Record a payment entry
Reconcile invoice and payment
Set invoice status to paid

invoice

Record an invoice entry only
Set invoice status to unpaid
Reconcile once payment is recorded

invoice_payment (`invoiceInformation.status = paid`)

Record a payment entry only
Reconcile using reconciliationId
Set invoice status to paid

invoice_payment (`invoiceInformation.status = failed_payment`)

If the bank rejects the payment and funds return to the Pleo wallet:

Record a return vendor payment
Set invoice status to unpaid

4. Recording and Reconciliation

Detection

Both invoice and payment entries exist.

Rule

The integration must reconcile invoice and payment entries. Reconciliation may occur across Export Jobs. After reconciliation:

Invoice payment status must be set to paid.

5. Special Cases

Refunds and Chargebacks

Detection

Export Item type is refund or chargeback.

Rule

If supported by the Accounting System:

Record a credit note instead of an invoice
Record the corresponding refund payment
Reconcile credit note and payment
Set credit note status to paid

Split Expenses

Detection

If the Export Item contains more than one split line (accountingEntryLines.length > 1), it must be treated as a split expense.

Rule

Record each split line as a separate line on the invoice
Record a single payment line representing the total amount across all splits
Reconcile invoice lines with the payment as usual

Example

Create the following in your Accounting System if the expense has 2 splits:

Line 1 (API): £120 → create 1 invoice line
Line 2 (API): £80 → create 1 invoice line
Line 3 (calculated total): £200 → create 1 payment line

Upstream Dependencies

Export Job has been claimed (status = in_progress)
Fetch Export Item Data (data layer)
Bookkeeping method resolved

Downstream Dependencies

Accounts Payable entries rely on several platform concepts to be complete and reconcilable:

Accounts Mapping – determines which GL accounts are debited and credited
Data Mapping – ensures amounts, dates, dimensions, identifiers, and VAT/tax information are recorded correctly
Attachment Handling – links receipts and supporting documentation
Accounting Periods – assigns entries to the correct accounting period
Posting Behaviour – determines whether entries are created as drafts or finalised
Export Item status update – updates outcome of Export Item (successful or failed)
Export Job status update – updates outcome of Export Job (completed, completed_with_errors or failed)

What Comes Next?

Accounts Mapping

Get Started

Integration Design

Workflow Guides

How-to's

Accounts Payable Handling

Implementation

Processing Model

1. Vendor Resolution

Detection

Rule

Failure Behaviour

Legacy Support

2. Invoice and Payment Model

Detection

Rule

Behaviour Notes

3. Expense Type Handling

Detection

Rule

card_invoice, card_purchase, fee

invoice

invoice_payment (`invoiceInformation.status = paid`)

invoice_payment (`invoiceInformation.status = failed_payment`)

4. Recording and Reconciliation

Detection

Rule

5. Special Cases

Refunds and Chargebacks

Detection

Rule

Split Expenses

Detection

Rule

Example

Upstream Dependencies

Downstream Dependencies

What Comes Next?

Get Started

Integration Design

Workflow Guides

How-to's

​Implementation

​Processing Model

​1. Vendor Resolution

​Detection

​Rule

​Failure Behaviour

​Legacy Support

​2. Invoice and Payment Model

​Detection

​Rule

​Behaviour Notes

​3. Expense Type Handling

​Detection

​Rule

​card_invoice, card_purchase, fee

​invoice

​invoice_payment (invoiceInformation.status = paid)

​invoice_payment (invoiceInformation.status = failed_payment)

​4. Recording and Reconciliation

​Detection

​Rule

​5. Special Cases

​Refunds and Chargebacks

​Detection

​Rule

​Split Expenses

​Detection

​Rule

​Example

​Upstream Dependencies

​Downstream Dependencies

​What Comes Next?

​Related Reading

Implementation

Processing Model

1. Vendor Resolution

Detection

Rule

Failure Behaviour

Legacy Support

2. Invoice and Payment Model

Detection

Rule

Behaviour Notes

3. Expense Type Handling

Detection

Rule

card_invoice, card_purchase, fee

invoice

invoice_payment (`invoiceInformation.status = paid`)

invoice_payment (`invoiceInformation.status = failed_payment`)

4. Recording and Reconciliation

Detection

Rule

5. Special Cases

Refunds and Chargebacks

Detection

Rule

Split Expenses

Detection

Rule

Example

Upstream Dependencies

Downstream Dependencies

What Comes Next?

Related Reading