Foreign-Currency AP Aging Automation in 2026: PO Dates, Invoice-Date Rates, Payment-Run Checks, and ERP Exports

The AP problem is not just conversion

A supplier invoice rarely has one correct FX moment for every purpose. Procurement may care about the PO date because that is when the commitment was approved. Accounting may use the invoice date for aging and accrual review. Treasury may need a fresh view before the payment run. Support or vendor management may need a historical replay when a supplier disputes the paid amount.

If those views are calculated in separate spreadsheets, the organization gets a familiar close problem: numbers that are all defensible in isolation but impossible to reconcile. The better pattern is to create one AP FX evidence path that stores policy date, exchangeRate, converted amount, rateTime, reviewer, and run ID with each payable row.

Currency-Exchange.app verifies the pieces needed for that workflow in the public API surface: conversion, exchange-rate lookup, historical date lookup, supported-currency metadata, API key controls, rate-limit headers, usage statistics, and downloadable usage exports. The workflow is API-based; the ERP, spreadsheet, or no-code tool is the surface that runs or reviews it.

Step-by-step AP aging workflow

Date policies AP should keep separate

The most important control is not the endpoint. It is the date rule. Keep the date views separate and name the purpose of each one, especially when a supplier invoice crosses a month-end boundary.

API examples for payables

Use conversion when the AP row needs a functional-currency amount. The example below converts a EUR supplier invoice into USD on the invoice policy date.

curl "https://api.currency-exchange.app/v1-convert-currency?from=EUR&to=USD&amount=18400&date=2026-05-31" \
  -H "x-api-key: YOUR_API_KEY"

Use rate lookup when the job needs the rate, inverse rate, and timestamp for a payment-run control before funding.

curl -i "https://api.currency-exchange.app/v1-get-currency-exchange-rate?from=EUR&to=USD&skipCache=true&cacheTimeSeconds=0" \
  -H "x-api-key: YOUR_API_KEY"

Use currency metadata before export so AP does not send unsupported or malformed currencies downstream.

curl "https://api.currency-exchange.app/v1-list-currencies?code[]=EUR&code[]=USD&code[]=JPY&expand[]=units&pageSize=50" \
  -H "x-api-key: YOUR_API_KEY"

TypeScript worker pattern

This worker keeps the invoice-date value and the payment-run variance separate. The point is not to hide volatility; it is to route it before the ERP export or bank file.

type PayableInvoice = {
  supplierId: string;
  invoiceId: string;
  purchaseOrderId?: string;
  sourceAmount: number;
  sourceCurrency: string;
  functionalCurrency: string;
  invoiceDate: string;
  dueDate: string;
  paymentRunDate?: string;
};

type PayableFxEvidence = {
  invoiceId: string;
  supplierId: string;
  policyDate: string;
  sourceAmount: number;
  functionalAmount: number;
  exchangeRate: number;
  rateTime: string;
  varianceFromPaymentRun?: number;
  reviewStatus: 'approved' | 'review';
};

function roundMoney(value: number) {
  return Math.round(value * 100) / 100;
}

async function convertInvoice(invoice: PayableInvoice, policyDate: string) {
  const url = new URL('https://api.currency-exchange.app/v1-convert-currency');
  url.searchParams.set('from', invoice.sourceCurrency);
  url.searchParams.set('to', invoice.functionalCurrency);
  url.searchParams.set('amount', String(invoice.sourceAmount));
  url.searchParams.set('date', policyDate);

  const response = await fetch(url, {
    headers: { 'x-api-key': process.env.FX_API_KEY ?? '' },
  });

  if (!response.ok) {
    throw new Error('AP FX lookup failed for invoice ' + invoice.invoiceId + ': ' + response.status);
  }

  return (await response.json()) as {
    convertedAmount: number;
    exchangeRate: number;
    rateTime: string;
  };
}

export async function buildPayableFxEvidence(invoice: PayableInvoice): Promise<PayableFxEvidence> {
  const invoiceDateRate = await convertInvoice(invoice, invoice.invoiceDate);
  const paymentRunDate = invoice.paymentRunDate;
  let varianceFromPaymentRun: number | undefined;

  if (paymentRunDate) {
    const paymentRunRate = await convertInvoice(invoice, paymentRunDate);
    varianceFromPaymentRun = roundMoney(paymentRunRate.convertedAmount - invoiceDateRate.convertedAmount);
  }

  const reviewStatus =
    varianceFromPaymentRun !== undefined && Math.abs(varianceFromPaymentRun) > 100 ? 'review' : 'approved';

  return {
    invoiceId: invoice.invoiceId,
    supplierId: invoice.supplierId,
    policyDate: invoice.invoiceDate,
    sourceAmount: invoice.sourceAmount,
    functionalAmount: invoiceDateRate.convertedAmount,
    exchangeRate: invoiceDateRate.exchangeRate,
    rateTime: invoiceDateRate.rateTime,
    varianceFromPaymentRun,
    reviewStatus,
  };
}

Exception queue for AP operations

AP teams do not need every FX difference to become an incident. They need a triage table that tells the right owner what evidence is missing and what must be reviewed before the payment run.

Automation surfaces and what to avoid

A mature AP workflow can start as a spreadsheet and later move to a warehouse job, ERP scheduled export, or no-code worker. The important thing is that every surface reads from the same evidence and does not create a new FX truth.

Buyer framework for AP and procurement

What makes the AP angle net-new

AP aging is not the mirror image of AR aging. Receivables workflows ask when to collect from customers, how to show balances to sales, and how to route overdue accounts. Payables workflows ask which supplier obligations are real, which invoices are blocked, how much cash treasury needs for the payment run, and whether procurement approved the original foreign-currency commitment.

That distinction changes the automation design. AP needs purchase-order context, supplier master data, approval state, payment terms, and bank-file readiness. The FX step should therefore sit between invoice normalization and ERP export, not only inside a dashboard. A spreadsheet can review exceptions, a no-code worker can schedule pulls, and an ERP job can receive the approved rows, but the evidence model should be the same in every surface.

The best first pilot is one supplier group with a limited set of currency pairs. Run the invoice-date conversion, calculate payment-run variance, export usage evidence, and ask AP whether the output is clear enough to approve without another spreadsheet. If it is, the workflow is ready to expand.

Keep the pilot boring on purpose. Avoid custom rounding rules, exotic approval logic, and broad ERP rewrites until the team can prove that the basic evidence model survives one close period and one payment run. Once those records reconcile, extra automation has something dependable to build on.

FAQ

Internal links for the next build step

AP aging connects naturally to month-end controls, currency master data, and ERP integration. Use those guides when the workflow moves from a pilot batch into a repeatable finance operation.