Expense, approval, journal and payment terms
| Term | Meaning |
|---|---|
| Expense | Spending record with description, account, amount, date and Paid By |
| Employee / Manager | Legacy User references in this module |
| Vendor | Existing Supplier reference, with identity displayed from its Party |
| Category | Broad expense classification; does not select the GL account automatically |
| Account | Selected expense debit account |
| Approval Status | Amount-tier decision: not required, pending tier, approved or rejected |
| Expense Status | DRAFT, APPROVED, POSTED, IN_PAYMENT, PARTIALLY_PAID or PAID |
| Journal | Accounting recognition linked to the expense |
| Expense payment | EXPENSE_PAYMENT record created through the expense flow |
| Payment Status | Separate DRAFT / IN_PROCESS / POSTED / CANCELLED lifecycle |
| Amount Paid | Current expense counter of recorded reimbursement amounts |
| Amount Due | Expense total minus that counter in the employee recording flow |
| Included Tax Amount | Informational tax amount included in the recorded total |
| Reset | Changes a financial record state; not automatically a financial reversal or refund |
Example of distinct states
An employee expense can show PAID after payment records totalling its amount have been created, while those payments are still IN_PROCESS. That label does not prove they were validated, posted or settled by a bank. Cancelling one later does not automatically restore the expense counter.
For company-paid posting, the service creates a full payment and sets expense PAID, while the payment starts IN_PROCESS. It does not currently update the new expense's balance counters in that same path. Read the actual related records instead of treating all displays as one state.
Identifier distinctions
Expense ID, journal ID and payment ID are different records. Employee/manager User IDs are not HR Employee IDs or Partner IDs. The payment structure temporarily reuses a field named customerPartnerId for the expense recipient reference; that name is a compatibility detail, not permission to substitute a customer or interpret every recipient as a customer.
The internal payment number is not a bank confirmation, receipt attachment or Payroll payslip. The module is not an automatic bank settlement or taxable-pay calculation workflow.