Accounts Payable Overview

Read captured supplier bills as posting-ready vendor bills split into ready and held, and preview or post them to a simulated NetSuite sandbox with /v1/ap.

The Accounts Payable app reads the supplier bills a workspace has already captured and turns each into a posting-ready vendor bill: vendor, entity, payment terms, due date, and lines carrying account, department and class. It splits the bills into ready and held, and states the dollars at stake in the held ones. The work is deterministic. Nothing in this app calls a model or extracts a document; it reads documents that were captured before and checks them against the Money Found ledger and a few AP controls.

These endpoints belong to the Accounts Payable app (catalog slug payables). A workspace uses them after adding the app; GET /v1/apps lists the workspace's apps by slug. Where the bills come from is part of the app's configuration (bill_sources), and by default AP reads the ap_invoices role of the workspace's Money Found configuration. Amounts are in the ledger currency of that configuration; every bill also keeps its own currency and amount.

A bill is held when something stops it from being paid as printed. There are four hold reasons: above_contract (the invoice bills more than the contract allows, from an owed row of the ledger), duplicate (the same vendor, amount and date appears twice; the captured original is never the copy), missing_po (a bill of a kind that must carry a purchase order number has none) and vendor_unknown (the vendor has no NetSuite record, which applies only when vendor records are configured). Estimated and potential findings are notes on a bill and never holds.

Authentication uses a tlnc_ API key or an OAuth token in the Authorization: Bearer header. Reads need the read scope. The two writes, PUT /v1/ap/config and POST /v1/ap/netsuite/post, need the write scope and the key's person to be a member or above in the workspace. All routes act on the workspace of the key; the cross-workspace master view is rejected.

Worked Example: Review Held Bills, Then Post

Start with the overview for totals and gaps, read the worklist of held bills, then dry-run the posting to see which records would go to the sandbox.

curl "https://api.talonic.com/v1/ap/overview" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

curl "https://api.talonic.com/v1/ap/issues" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

curl -X POST "https://api.talonic.com/v1/ap/netsuite/post" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"dry_run": true}'

When the dry run looks right, post for real. The run is kept in the posting log and can be read back by id.

curl -X POST "https://api.talonic.com/v1/ap/netsuite/post" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

curl "https://api.talonic.com/v1/ap/netsuite/runs" \
  -H "Authorization: Bearer $TALONIC_API_KEY"