Skip to main content

Process a company-paid expense

COMPANY Paid By uses a supplier/vendor reference. The posting action creates an expense journal and a full EXPENSE_PAYMENT record, links them and sets the expense status PAID. The payment record begins IN_PROCESS; no bank initiation is performed.

Procedure​

  1. Enter a complete company-paid draft with the actual Supplier selected.
  2. Verify the stored owning unit, expense account, date, total and currency.
  3. Resolve the required manager/director decision.
  4. Move the expense to APPROVED through the guided action.
  5. Request posting and confirm once.
  6. Reload and inspect the returned expense, linked journal and created payment through authorised reads.
  7. Reconcile actual settlement and accounting under the approved finance process.

Example​

North Office Supplies provides GBP 240 of office goods. The initial journal debits the selected office EXPENSE account for 240 and credits account 2010 for 240. A full payment record is created using the stored expense unit, supplier recipient reference, method/date/currency and description.

This route does not expose the employee partial-reimbursement workflow. The journal page's normal PAY/payment-count navigation is limited to EMPLOYEE Paid By. Do not invent a company vendor settlement screen simply because the record exists in the backend.

An authorised support integration can inspect existing related records through the supported read APIs, using the normal authenticated tenant context:

GET /api/v1/expenses/501/journal
GET /api/v1/expenses/501/payments

Expense 501 is illustrative. Journal reads need expense view and journal view; payment-list reads need expense view and payment view, with their normal module/scope checks. The payment list is the full related list; the legacy journal/single-payment endpoint returns only its latest matching payment. These reads do not create settlement, repair counters or grant mutation authority.

Important current differences​

The company posting path sets PAID while payment is IN_PROCESS. It does not update the new expense's Amount Paid/Amount Due counters in that method. A recently created company expense can therefore show a PAID status with counters not reflecting a settled zero balance. Do not treat this as proof the bank paid or the payable has been cleared.

The payment payload temporarily reuses customerPartnerId for Supplier ID. Do not reinterpret that recipient as a customer, create a customer account to match it or copy arbitrary numeric IDs. Compatibility should be reviewed against the deployed payment schema.

Recovery​

Missing vendor blocks company-paid validation even though the generic form label says optional. If the posting response is uncertain, verify whether the journal/payment were already committed before repeating. If the financial state or balances disagree, preserve the linked IDs and ask finance/support to reconcile; do not manually change the expense to PAID as a substitute for settlement evidence.