Skip to main content
POST
Approve a vendor bill

Authorizations

Authorization
string
header
required

API key issued per entity via Settings > Developers > API Keys. Each key carries scopes (e.g. orders:read, products:write). Bearer token format: Authorization: Bearer ark_live_ent_Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.

Path Parameters

id
string<uuid>
required

Body

application/json
future_reason
string

Why the bill may post further ahead of today (UTC) than the entity's forward posting window. The window is re-read at approval, so a bill created inside it can be refused here; read only when the window refuses the bill's posting date. Granted when the approver holds accounting.close_period and a MONTHLY accounting period covers the date; recorded once, on the approval's audit row.

Required string length: 4 - 500
backdate_reason
string

The backward mirror of future_reason, for a posting date further back than the backdate window at approval.

Required string length: 4 - 500
allow_duplicate_override
boolean

Overrides a likely duplicate landed charge found at approval (the approval judges the landed lines it makes live, as create does), with duplicate_override_reason; audited.

duplicate_override_reason
string

Why the landed charge is separate (required with allow_duplicate_override; written to the audit trail).

Response

The bill is approved and posted. The answer is the approval itself, under data, not the bill record: its id, approval_status approved, the bill's new status, the journal entry the approval posted, the revaluation of any matched purchase-order lines, the fixed assets it created, the quick-check payment when one was taken, the landed warnings (every other landed bill on the receipts this approval allocates onto; allocated_on_these_receipts is omitted without the margin permission) and landed_duplicate_overridden when the approval overrode a likely duplicate landed charge. Read the bill with getVendorBillV1.

data
object