Invoice Overdue & Sales Order Blocking
Context
An enterprise sales application needed stronger controls around overdue invoices, payment collection, and Sales Order eligibility. The workflow served sales operations where unresolved financial status directly affected whether a new order could be created.
QA Role
I owned coverage for the affected web and mobile flows, from scenario design and test data through execution, defect follow-up, UAT support, and release regression. When UI status was unclear, I used Postman and MySQL to trace the underlying order and payment state.
Testing Scope
- Invoice due-date rules with due date <= today
- Sales Order blocking when unpaid overdue invoices exist
- Payment recovery and eligibility recalculation
- API response validation for blocked and eligible order states
- SQL validation for invoice status, overdue amount, and blocking reason
- BDD coverage for remaining invoice buffer behavior
Test Approach
Coverage focused on date boundaries and state transitions. Scenarios verified that a customer with an unpaid overdue invoice cannot create a Sales Order, then confirmed that a full payment recalculates eligibility and allows order creation again.
Tools
Postman, MySQL, Jira, and Google Drive.
Methods & Formats
Gherkin / BDD.
Project Evidence Set
Test Case
Project-specific functional and boundary scenarios for overdue invoices, blocking, payment recovery, and eligibility state.
API Testing
API-level validation for payment status, order eligibility, and transaction state changes.
SQL Validation
Database checks for invoice status, due date, outstanding amount, order blocking state, and audit trail.
Gherkin / BDD
Business-readable rules for outstanding payment collection, remaining invoice buffers, and eligible orders.
Bug Report
Reproducible findings with financial impact, affected state transition, expected behavior, evidence, and retest notes.
Business Impact
The release gained stronger protection against orders proceeding with unresolved financial conditions and against eligible customers remaining blocked after payment.
Confidentiality
This case study reflects real QA responsibilities. Product rules, identifiers, and selected details have been generalized to protect confidential information.