Historic payables data

APHistoricalData provides accounts payable history by company, branch, account, subaccount, currency, supplier and financial period. The APHistoricalData query and APHistoricalData type are available in the GraphQL reference for the schema contract.

Disabled during testing

APHistoricalData is disabled in Production while testing is in progress. The schema remains documented for reference; the APHistoricalData ETL is not available for Production use.

Availability depends on deployment and the required historical backfills. Seeing the API model in the schema does not activate the ETL or confirm that supplier history is populated.

Keys and balances

Each AP history row is identified by these fields:

Dimension	Field
Company	companyId
Branch	branchId
Account	accountId
Subaccount	subaccountId
Currency	currencyId
Supplier	supplierId
Financial period	finPeriodId

Financial periods use the ERP YYYYPP format. PP is the configured financial-period number, so it must not be treated as a calendar month without checking the company's financial-period setup.

beginningBalance and endingBalance are base-currency values. beginningBalanceInCurrency and endingBalanceInCurrency are the corresponding values in the currency identified by currencyId. revaluedGainLoss is supplied in base currency only; there is no corresponding revaluedGainLossInCurrency field.

An AP history row is a snapshot for its selected financial period. Its ending balance is the balance at that period's end, not a current balance after later activity. For example, in a single currency, a year-end row with a beginning balance of 100000 and a reduction of 10000 can show 100000 - 10000 = 90000. This illustrates the period snapshot only; it does not define sign handling or establish parity with a complete ERP report.

The GraphQL field detailDeleted maps to the source DetDeleted flag on CuryAPHistory. It indicates the source history detail's deletion marker. It is not DataMart hard-delete tracking. The AP history query has no includeDeleted argument, and the APHistoricalData type has no deletedDatabaseRecord field.

The query accepts cursor and update-window arguments, not a where argument. For example, this page request selects the complete history key and balance fields:

query APHistoryPage(
  $lastId: String
  $updatedInDataMart: DateTime
  $updatedInDataMartTo: DateTime
  $pageSize: Int! = 5000
) {
  apHistoricalData(
    lastId: $lastId
    updatedInDataMart: $updatedInDataMart
    updatedInDataMartTo: $updatedInDataMartTo
    pageSize: $pageSize
  ) {
    companyId
    branchId
    accountId
    subaccountId
    currencyId
    supplierId
    finPeriodId
    beginningBalance
    endingBalance
    beginningBalanceInCurrency
    endingBalanceInCurrency
    revaluedGainLoss
    detailDeleted
  }
}

The authorized request context supplies the company scope. companyId is returned as part of each history key; it is not a query argument.

Relating history to documents and applications

AP history is sourced from CuryAPHistory. To relate supplier documents and payment applications, keep the company in every join.

Supplier documents

The natural key of a supplierDocuments record is:

companyId + documentType + referenceNumber

The four document fields to read from the linked supplier document are released, voided, prebooked and installmentCntr.

Supplier payments

The natural key of a supplierPayments record is:

companyId + documentType + refNbr

It matches the payment side of a payment line: documentType = paymentDocType and refNbr = paymentRefNbr, within the same companyId.

Supplier payments expose five header fields for historic payables:

Field	Meaning
paymentDate	The document date of the payment.
financialPeriod	The financial period the payment was posted in, in the YYYYPP format.
branchId	The ID of the branch.
paymentAmountInBaseCurrency	The payment amount in the company's base currency. The existing paymentAmount stays in the payment's document currency.
voided	Indicates if the payment has been voided.

financialPeriod is the payment's own financial period. It is nullable: it is always set for active payments, but a deleted payment that was removed from ERP before the field was introduced returns null. It differs from the existing applicationPeriod and applicationDate fields, which describe the application.

Payment applications

On supplierPaymentLines, link the adjusted supplier document with the exact keys:

Supplier document	Supplier payment line
companyId	companyId
documentType	invoiceDocType
referenceNumber	invoiceRefNbr

The full natural key of a supplier payment-line application is companyId + paymentDocType + paymentRefNbr + invoiceDocType + invoiceRefNbr + adjNbr. The payment side is paymentDocType + paymentRefNbr; the adjusted-document side is invoiceDocType + invoiceRefNbr; and adjNbr identifies the individual application.

The ten application fields are released, voided, postPeriodId, amountApplied, amountAppliedInCurrency, cashDiscountApplied, cashDiscountAppliedInCurrency, withholdingTaxApplied, withholdingTaxAppliedInCurrency and voidAdjNbr. postPeriodId is the financial period the application is posted to. It matches postPeriod on the payment lines of the Visma.net REST API supplierPayment endpoint, and has the same value as applicationPeriod. It is nullable: it is always set for active lines, but a line that has not been backfilled yet, or a deleted line that was removed from ERP before the field was introduced, returns null.

The ...InCurrency application amounts belong to the adjusted document's currency. The corresponding fields without InCurrency are base-currency amounts. For the adjusted document's own financial period, read financialPeriod on the linked supplier document.

Aggregate AP history at the intended reporting grain before joining currency slices or raw supplier documents and applications. A one-to-many join before aggregation can repeat the same base balance, so do not multiply base balances by joining those rows to history before aggregating.