The Candis Export API allows you to retrieve approved invoice data from Candis for processing in your accounting or ERP system. The following endpoints are available:

1. Create an Export
2. Get a List of Exports
3. Get an Export
4. Get a List of Export Postings
5. Download PDF File by ID

Create an Export

This endpoint initiates the creation of an export containing all approved invoices in Candis. The export represents a permanent snapshot of the data.

Once exported:

• The document can no longer be deleted or sent back for approval.
• Details such as the accounts payable number or general ledger account can no longer be modified.
• An export ID is generated, which is required for subsequent endpoints.

Supported entityType values:

• DOCUMENT (default)
• CARD_TRANSACTION
• REIMBURSEMENT_ITEM

By default, only invoices of type DOCUMENT are included unless CARD_TRANSACTION is explicitly specified.

Get a list Exports

Returns a list of all export records along with their export IDs.

Use cases:

• Identify duplicate exports
• Verify that all exports have been processed

Get an Export

Retrieves the status of a specific export using its export ID.

Export statuses:

• EXPORTING → Export is in progress
• EXPORTED → Export is complete

Note: You should poll this endpoint at regular intervals to avoid unnecessary delays in the export process.

Get a list of Export Postings

Once the export status is EXPORTED, you can retrieve the related postings (line items) using this endpoint.

Supported entityType values:

DOCUMENT
Used for invoice-based entries.

Subtypes:

• Incoming Invoice (Rechnungseingang)
• Outgoing Invoice (Rechnungsausgang)
• Invoice Correction (Rechnungskorrektur)

These are the most commonly used documents for standard accounts payable/receivable processing.

Note: Depending on the language selected by the customer, either the German or English names will appear in the export.

When purchase orders, goods receipts, or additional delivery costs have been imported via the Core Data API and matched to invoices, each split posting in the export may contain additional metadata:

• purchaseOrderMetadata — References to matched purchase order lines
• goodsReceiptMetadata — References to matched goods receipt lines
• additionalDeliveryCostsMetadata — References to additional delivery cost codes

Split postings also have a type field that distinguishes between regular line items (ITEM) and supplementary delivery charges (ADDITIONAL_DELIVERY_COST).

CARD_TRANSACTION
Used for exports related to credit card usage and settlements.

Subtypes:

• DOCUMENT – Represents the original invoice related to the card payment
• CARD_TRANSACTION – The actual credit card transaction record
• CARD_SETTLEMENT – The settlement/clearing of the card balance

These allow the correct reconstruction of payment flows via credit cards.

REIMBURSEMENT_ITEM
Used for employee expense reimbursements.

Subtypes:

• GENERAL_EXPENSE – Regular expense items (e.g. office supplies, parking fees)
• HOSPITALITY_EXPENSE – Expenses for meals, client events, etc.
• PER_DIEM – Daily allowances (e.g. travel per diems)
• MILEAGE – Kilometers driven using a private vehicle for work purposes

Specifics for CARD_TRANSACTION:

When the export includes CARD_TRANSACTION data, the posting structure extends the DOCUMENT format with the following additional objects:

• creditCardSettings
  • bookingAccount
  • transitAccount
• payment
  • method
  • paidAt

Posting Logic for Credit Card Transactions
In your ERP system, an additional posting must be created using the following changes:

1. Replace invoiceDate with paidAt
2. Replace generalLedgerAccount with bookingAccount
3. The invoice posting increases the liability (payable) to the vendor.
   The credit card transaction reduces the same payable by the same amount.

This structure allows you to correctly reflect the financial transaction flow in your ERP.

Best Practice

Example Scenario

Vendor invoice paid with a credit card.

Invoice details

Posting 1 — Incoming Invoice (DOCUMENT)

This represents the original vendor invoice.

Accounting Entry

Posting 2 — Credit Card Transaction (CARD_TRANSACTION)

This posting represents the payment made via the credit card.

Changes compared to the DOCUMENT:

Accounting Entry

This clears the vendor liability and moves the balance to the credit card account.

Posting 3 — Card Settlement (CARD_SETTLEMENT)

When the credit card provider withdraws the money from the bank account.

Accounting Entry

This clears the credit card account against the bank.

Resulting Accounting Flow Expense → Vendor liability → Credit card → Bank

1. Expense recognized from invoice
2. Vendor payable created
3. Payable cleared by credit card
4. Credit card settled via bank

✅ Best practice summary

• Always create two postings: invoice + credit card transaction • Use paidAt as the posting date for the credit card payment • Replace generalLedgerAccount with bookingAccount • The credit card posting must clear the vendor payable • Settlement postings should clear the credit card account against the bank

Three-way matching in exports

For organizations using purchase orders and goods receipts, the export flow supports end-to-end reconciliation:

1. Import purchase orders, goods receipts, and additional delivery costs via the Core Data API
2. Match invoices to purchase orders and goods receipts during the Candis approval workflow
3. Export postings with full metadata references for automated ERP reconciliation

The purchaseOrderMetadata field in each split posting contains references to the matched PO lines (including order number). The goodsReceiptMetadata field contains references to matched goods receipt lines. The additionalDeliveryCostsMetadata field contains the delivery cost codes for supplementary charge line items.

Download PDF file by ID

Use this endpoint to retrieve PDF document images associated with an export.

Supported file types:

• Main document → INVOICE, XRECHNUNG
• Attachments → ATTACHMENT
• Summary document → AUDIT_TRAIL (Approval trail)