Skip to main content

​
📄 Guide

“Who can spend, how much, and on what” is expressed by velocity rules; “how much was spent, and when it is due” is expressed by statements. This page explains the binding semantics of rules and the billing conventions of statements.

​
Velocity limits

Spend control is implemented through standalone velocity-rule objects. Rules are created by the partner, belong to the company level, and apply to cards (CARD) or employees (EMPLOYEE) through targets — a many-to-many relationship. When an object has several rules bound, the system takes the minimum on every dimension, so the strictest limit always wins. The full endpoint definitions are in the API reference.
Velocity rule binding and the authorization checkVelocity rule binding and the authorization check
  • Control dimensions. Purchase and cash-withdrawal limits are independent groups; each can set per-transaction and daily / monthly / quarterly / yearly caps on amount and count per currency, overlaid with allow/deny lists for transaction currency, MCC and region.
  • Binding and caps. Rules can be bound at card application time through ruleIds (at most 5); a company-funded card (SHARED — paid from company funds) must have at least 1 rule bound. A single card and a single employee can each carry at most 5 rules.
  • Rule status. A rule switches between ACTIVE and INACTIVE: an INACTIVE rule takes no part in transaction checks but keeps its existing targets.

​
Statements and cycles

DCS issues a statement automatically per calendar month for every billing entity — no partner trigger needed. Statement data is pulled over the API.
Cycle, statement day and due dateCycle, statement day and due date
  • Cycle and key dates: the cycle is the calendar month (format yyyy-MM); each month’s statement day issues the previous month’s statement; any debt must be repaid by the due date (paymentDueDate).
  • Settled vs open statements: a settled statement (SETTLED) is fixed and contains only posted transactions; the open statement (OPEN, statementId null) is a live summary of the current cycle that includes unsettled authorization holds, so its spend total falls back as transactions clear — expected behavior. Treat the settled statement as final.
  • Billing entity: the balance mode decides who gets billed: the company pool (SHARED) yields one statement per company; dedicated balances (DEDICATED) yield one statement per card.

​
Next steps