Current implementation limits to review before use
These findings come from current source review. They are included so procedures remain truthful, not as instructions to bypass controls. This documentation does not repair application behaviour or claim live end-to-end verification.
Financial and workflow limits
| Finding | Practical implication |
|---|---|
| Employee reimbursement dialog sends businessUnitId 1; service does not replace it | Related payment can fail access or differ from expense unit; review before branch use |
| Employee counters change at payment creation | PAID/due-zero can precede payment posting or actual settlement |
| Cancel/reset wrappers do not recalculate counters | Do not assume due is restored; reconcile before a replacement record |
| Company posting sets PAID but creates IN_PROCESS and does not update counters there | Label/counters/payment can disagree |
| Generated base GBP/rate 1, payment date copied from expense date | No reliable general FX or separate actual-reimbursement-date workflow |
| Included tax not split in journal and not editable in update | No automatic input-tax recovery/correction procedure |
| Status service lacks a full guided transition matrix | Do not claim universal server-enforced approval ordering or safe status jumps |
| Approval reset only on changed total | Same-amount material edits can retain decisions; same-amount rejection resubmission absent |
| No independent reviewer/selected-manager enforcement | Follow approved separation of duties outside the code's stated checks |
| No request idempotency/explicit expected-version workflow | Coordinate edits; establish outcome before retrying financial mutations |
| Payment lifecycle delegates generic payment state methods | It does not establish a complete expense-liability clearing/reversal accounting process |
UI and compatibility limits
Account/Vendor generic optional labels do not override create account and company-vendor requirements. Autocomplete text is not a selected identity. Null merge updates cannot reliably clear optional saved references. New vendors are active Supplier choices; edit can preserve an existing vendor when lookup is unavailable.
Employee/Manager are login Users, not HR Employee records. Recipient values are passed through the legacy payment customerPartnerId field. Validate the deployed compatibility contract; never create matching numeric identities or reinterpret IDs to satisfy another module.
Journal read failures can remove the detail link; payment read failures can show zero counts. Error fallback is not evidence of no posted records. Company-paid records lack the normal employee payment-navigation control, although related API reads exist.
The current Expense response exposes display names/account code but omits several raw reference IDs, the stored unit and an expected-version value. Some identity/unit investigations therefore need authorised support or the owning lookup context rather than an invented detail field. Edit preserves an unchanged vendor by omitting its ID instead of guessing it from the name.
How to act on a limitation
Record the exact affected operation and observed saved state, keep non-secret IDs/evidence references, and obtain the approved finance/support resolution. Do not invent a balance-repair endpoint, token amount change, automatic reversal or bank instruction. Product changes need a separate implementation task and tests.
Use an approved test tenant before accepting these workflows for a release, especially multi-unit, non-GBP, cancellation/reset and company-settlement cases. The guide makes no claim that draft acceptance or a successful service-unit test proves those complete operational flows.