Skip to main content

Thirty-five worked Expenses scenarios

These exercises use invented Bright Haven Services data. Use approved training records and verified tenant IDs. Financial examples explain current record effects; they do not certify bank settlement or a complete production accounting workflow. Read Known limits before the payment exercises.

1. Employee travel draft​

Select Amira's login User, TRAVEL, an approved expense account, GBP 120, the actual date and EMPLOYEE Paid By. Save and inspect DRAFT and due 120.

Expected: No journal/payment yet. Recovery: If account selection is missing, choose an actual option despite the optional label. See Create.

2. Company office purchase​

Select COMPANY and the active Supplier North Office Supplies with the approved office expense account and GBP 240.

Expected: Draft stores supplier context; later posting uses company path. Recovery: Missing vendor is rejected even though the form's generic label says optional.

3. Do not substitute HR Employee IDs​

Amira has HR Employee #201 and login User #301. Select the User through Expenses, not #201 through an API.

Expected: Correct legacy identity and unit resolution. Recovery: An HR link does not migrate Expense references. See Identities.

4. Manager option does not grant approval​

Farah selects Jonah as Manager, but he lacks expense.manager-approve.

Expected: Selected reference does not authorise a decision. Recovery: Review actual approved permission grants; do not assume the Manager field routes a mandatory workflow to him.

5. Primary unit determines ownership​

Amira has North primary and South allowed. Create a new expense after checking the intended ownership.

Expected: North is captured, regardless of where the preparer is physically located. Recovery: There is no create-form unit selector; resolve the approved primary configuration first.

6. User moves after an expense exists​

Amira's primary later becomes South. Reload the existing North expense.

Expected: Stored ownership remains North. Recovery: Do not recreate the same spending or assume User grants migrated old journals. See Units.

7. No User unit configured​

The selected User has no eligible active non-denied unit access. Creation/posting reports the setup problem.

Expected: No guessed owning unit. Recovery: Authorised Administration fixes real access; do not choose an unrelated User to pass.

8. Category and account are separate​

Choose TRAVEL and finance's approved travel debit account explicitly.

Expected: Category is a label; posting uses selected Account. Recovery: No automatic account mapping is created by choosing TRAVEL. See Categories/accounts.

9. Included tax stays inside total​

Enter total 120 and included tax 20.

Expected: Due starts at 120, not 140. Initial journal currently uses full 120 without separate tax recovery. Recovery: Use the approved tax/accounting process; do not assume input-tax posting. See Amounts/tax.

10. Wrong included tax discovered​

A draft has correct total but incorrect tax. Edit hides tax and its request cannot update it.

Expected: No invented Edit tax action. Recovery: Obtain the approved draft correction/deletion/recreation or support procedure before financial effects; preserve evidence.

11. Unselected vendor text​

During edit, Farah types a new supplier name but does not choose a result.

Expected: Free text is not a new vendor; existing reference may remain. Recovery: Select the verified Supplier or cancel the attempted replacement, then reload saved data.

12. Null does not clear Manager​

An update sends null for Manager on a draft that already has one.

Expected: Merge semantics preserve existing Manager. Recovery: Do not assume the blank control removed the saved reference; use the supported authorised correction process. See Edit.

13. Delete an accidental unused draft​

Verify the exact DRAFT duplicate, no financial effects and deletion authority; choose Delete and confirm.

Expected: Draft removed, no refund/reversal. Recovery: A posted error is a finance issue, not a reason to force status back to DRAFT. See Delete.

14. Amount at the lower approval boundary​

Create total 5000.00.

Expected: NOT_REQUIRED; separate lifecycle Approve still needed. Recovery: Do not assume no-threshold approval means auto-posted.

15. Amount just over the lower boundary​

Create total 5000.01.

Expected: MANAGER_APPROVAL_REQUIRED. Recovery: The approval action needs matching authority; a selected manager name alone is insufficient. See Thresholds.

16. Amount at the director boundary​

Compare 50000.00 and 50000.01.

Expected: The former requires manager; the latter director. Recovery: The current policy is not a sequential two-tier chain or currency conversion policy.

17. Resolve decision then lifecycle separately​

Jonah approves a pending 6000 manager-tier decision. Farah then performs the authorised DRAFT → APPROVED action.

Expected: Two different effects; journal still absent until posting. Recovery: Decision success does not grant Farah status-update authority. See Decisions.

18. Reject with a meaningful reason​

Use Reject on a pending decision and provide the actual explanation.

Expected: REJECTED and lifecycle approval blocked. Recovery: Blank reason fails; rejection is not payment cancellation. See Rejection.

19. Genuine amount correction after rejection​

Evidence shows entered 6500 should be 6000. Correct the DRAFT total.

Expected: Requirement recalculated and old decision metadata cleared. Recovery: Re-review the newly pending requirement; do not claim the earlier decision still applies.

20. Same-amount rejected rework​

The 6000 total was correct but description was wrong. Fixing description leaves the rejected decision unchanged.

Expected: Current resubmission gap remains. Recovery: Use approved support/product resolution; do not fabricate a penny change or threshold reduction to reset it.

21. Other material edit retains decision​

A draft's expense account changes while its total stays the same.

Expected: Current code may retain old approval metadata. Recovery: Arrange required re-review rather than claiming every field change automatically invalidates approval.

22. Post employee spending​

Complete guided approval and post employee-paid GBP 120.

Expected: Debit selected expense 120, credit payable 2020 for 120, expense POSTED and no payment yet. Recovery: Missing account/setup requires approved resolution. See Employee posting.

23. Post company spending​

Complete guided approval and post company GBP 240 with vendor.

Expected: Journal credits 2010; full payment starts IN_PROCESS; expense label PAID. Recovery: Counters/label do not prove actual settlement and company UI lacks the employee PAY navigation. See Company posting.

24. First partial reimbursement​

For a posted employee total 300, record 100 only after the unit/recipient setup is approved and reviewed.

Expected: Payment IN_PROCESS; counter paid 100/due 200; PARTIALLY_PAID. Recovery: Verify payment unit, especially current dialog ID 1, before treating this as a safe branch workflow.

25. Complete recorded payments​

After recording 100, record the approved remaining 200.

Expected: Counters 300/0 and PAID; individual payment validation/settlement can still be outstanding.

Recovery: Do not equate counters with bank settlement. See Partial payments.

26. Attempt above remaining due​

Due is 200 and someone tries to record 250.

Expected: Sequential overpayment check refuses it. Recovery: Reload actual due/payment list; do not split an unjustified excess into more requests.

27. Cancel an IN_PROCESS payment​

Cancel a permitted 100 row after approved review.

Expected: Row can become CANCELLED while parent counters still include 100. Recovery: Reconcile before another record; no automatic due restoration. See Payment actions.

28. Reset and confirm a payment​

Reset an eligible POSTED/CANCELLED row to DRAFT, then Confirm moves it IN_PROCESS; Validate can later post it.

Expected: Payment-state changes only, not an automatic refund/inverse/balance rebuild. Recovery: Do not use this sequence as an undocumented correction strategy.

29. Reset a linked journal​

An authorised operator resets a linked posted journal under Accounting's rules.

Expected: Expense state and payment counters are not automatically reset alongside it. Recovery: Review the entire relationship before further financial action. See Journal actions.

30. Non-GBP draft​

A EUR expense is accepted by the currency picker.

Expected: That does not prove economically correct GBP-base posting; builder currently uses GBP/rate 1. Recovery: Obtain approved finance handling, never relabel currency. See Currency/dates.

31. Later reimbursement date​

Spending occurred 1 November, reimbursement is arranged 8 November.

Expected: Generated payment date currently copies 1 November. Recovery: Retain actual settlement evidence separately; do not claim the displayed date proves the bank transfer date.

32. Search by vendor/user correctly​

Searching the global box for a Supplier name may not find foreign-key display names. Select the actual Vendor/Employee filter and check date/status chips.

Expected: Search respects its real stored-field scope. Recovery: Check paging/allowed units before recreating an apparently missing expense. See Navigation.

33. Journal read fails after posting​

The detail link disappears because the journal request failed.

Expected: UI absence is not proof no journal committed. Recovery: Retry authorised reads or ask support before another post. See Recovery.

34. Lost reimbursement response​

The network fails after Record Payment was submitted.

Expected: Outcome uncertain; no original-intent replay is promised. Recovery: Reload newest payment rows/counters and establish outcome before repeating. Coordinate concurrent recorders.

35. Reconcile without inventing clearing​

Compare expense facts, current approval metadata, initial journal, every payment and external settlement evidence.

Expected: Discrepancies are documented with exact non-secret IDs/states, not hidden by a PAID label. Recovery: The reviewed lifecycle does not establish automatic expense-payable clearing/reversal; use approved finance/support resolution. See Reconciliation.