The most critical business risk in the entire feature. If Outlet-to-Company mapping logic is incorrect, credits are applied to the wrong company. This causes financial loss for one company and illegal enrichment of another — with no visible error to the user. The damage may only be discovered during manual financial reconciliation, potentially weeks or months later.

If the database transaction is not fully atomic, a failure mid-write (e.g., after crediting Company A but before Company B) leaves the system in an inconsistent state. Company A has excess credits; Company B is under-credited. The QuickBooks quotation exists for the full amount. No rollback occurs. This is an undetectable financial inconsistency without an explicit comparison job.

Without idempotency protection (unique Transaction IDs), a retry, double-click, or network replay could create two or more QuickBooks quotations for the same top-up event. This results in double-billing the client and potentially double-crediting SMS tokens — a direct financial fraud risk.

QuickBooks is an external third-party SaaS service with its own SLA. During planned or unplanned downtime, the entire SMS top-up workflow is blocked. Without proper retry logic and graceful degradation, the system may hang indefinitely, throw unhandled exceptions, or — most critically — proceed to credit SMS tokens without a valid quotation.

A malicious Finance Executive (or an external attacker who has gained authenticated access) could attempt SQL injection, XSS, or server-side request forgery through the top-up amount fields. Client-side-only validation provides zero protection against direct API manipulation via tools like Postman or curl.

In the worst-case scenario, if both the credit write AND the rollback mechanism fail simultaneously, the system enters an unknown state. Without an admin escalation path, this inconsistency may go undetected. The DB is in a partially written state with no automatic recovery — requiring dangerous manual intervention without transaction context.

When two Finance Executives submit top-up transactions for the same Brand simultaneously, a race condition on the Company credit record could result in a "lost update" — where one transaction's write overwrites the other's. Final company balance would be incorrect (showing only one submission's credits instead of both).

A user rapidly double-clicking the Submit button could trigger two simultaneous API calls before the first response is received. Without button-state management, this results in two QuickBooks quotations and potentially double SMS credits — without the user realising any error has occurred.

If input validation exists only on the client side (JavaScript), any authenticated user can bypass it using browser developer tools, Postman, or curl. Negative values, text strings, or injected payloads could reach the server and the QuickBooks API unchecked.

QuickBooks may return unexpected responses — HTML error pages instead of JSON, empty response bodies, or partial JSON. If the system does not guard against this, an unhandled JSON parsing exception could expose raw server errors to the user, crash the transaction flow, and leave the audit log incomplete.

Floating-point arithmetic can produce rounding errors (e.g., 100.999 + 200.001 ≠ 301.00 in some environments). Mitigation: Use fixed-precision arithmetic (DECIMAL type in DB, avoid float/double for monetary values). System must explicitly define and enforce maximum 2 decimal places. TC10 tests this boundary.

If audit log entries are incomplete (missing Transaction ID, user ID, amounts, or status), financial reconciliation and regulatory audits become impossible. Mitigation: Define mandatory audit log schema. Verify all required fields in TC24. Audit log write failure must NOT silently pass — log the log failure to a secondary channel.

If the client's email address in QuickBooks is null, empty, or malformed, the system may throw an unhandled null pointer or SMTP exception — potentially crashing the flow before SMS credits are applied, despite the email step being non-blocking by design. Mitigation: Explicitly validate email field before any send attempt. Catch null/empty as a graceful skip. TC19 tests null, empty, whitespace, and invalid format variants.

SMTP outages prevent client notification emails. By design, email failure is non-blocking — SMS credits proceed regardless. However, without a retry queue, the failure is permanent. Mitigation: Implement email retry queue (e.g., dead-letter queue with 3 retry attempts over 24 hours). Finance Executive shown a non-critical warning. TC18 validates non-blocking behaviour.

Brands with 50+ outlets may cause UI rendering delays or dropdown freezing. Aggregation of 50 outlet amounts before submission may also cause perceptible delay. Mitigation: Paginate or virtualise large outlet lists. Implement client-side debounced aggregation. TC03 establishes performance baseline and documents acceptable thresholds.

Email template caching or incorrect variable binding could result in a previous transaction's data (amount, client name, brand) appearing in the current email. Clients receive an email with the wrong financial details. Mitigation: Each email must be freshly rendered per-transaction. TC20 explicitly verifies email content accuracy for each field, and runs two consecutive transactions to detect cross-contamination.

Input such as "1e9" (1,000,000,000) may pass type="number" HTML validation while being an unexpectedly large value. Some numeric parsers accept scientific notation. Mitigation: Explicitly disallow scientific notation in server-side validation. Define and enforce a maximum permitted top-up value. TC08 specifically tests this input variant.

If one outlet field fails validation and the system resets all other fields, the Finance Executive must re-enter all amounts — a poor UX experience that may lead to re-entry errors. Mitigation: Only highlight and focus the invalid field. All valid fields retain their values. TC05 and TC12 document expected field isolation behaviour. Log as UX defect if reset occurs.

If QuickBooks API timeout is hardcoded (e.g., always 30s), it cannot be adjusted for different environments or QuickBooks SLA changes without a code deployment. Mitigation: Timeout value must be environment-variable configurable. TC14 records the actual configured timeout value in the test report for documentation.