- Checks Module
 

Supervised, auditable, and legally traceable check payment management
 

- Conceptual Overview (What the Checks Module Really Is)
 

The Checks Module is a dedicated financial control layer exclusively designed for managing check payments, which are fundamentally different from digital payments.
 

Unlike credit cards or bank transfers, checks are a deferred, conditional, and legally sensitive payment method.
They may:
 

• Be deposited days later

• Bounce due to technical or legal reasons

• Enter legal collection processes

• Require manual tracking and documentation
   

For these reasons, the Checks Module exists as a dedicated operational system, not just another payment list.
 

- Why Checks Require Their Own Module
 

Checks present risk, delay, and legal exposure.
 

This module ensures:
 

• Every check has a lifecycle

• Every status change is intentional

• Every bounce is explicitly documented

• Every image is saved and traceable

• Every check is owned by a responsible team member
   

Without this structure, checks would become financial blind spots.
 

- Check Lifecycle (High-Level Flow)


Check Received
   │
   ▼
In Process
   │
   ├─► Paid
   │
   ├─► In Agreement
   │
   └─► Legal / Attorney

 

Each stage reflects a real banking and legal status, not just an internal label.
 

- Status System (Operational Meaning, Not Just Colors)
 

Each check status represents a financial and legal state:
 

• Paid (Green)
  
  The check cleared the bank. Funds confirmed. No further action needed.
   

• In Process (Yellow)
  
  The check has been deposited or is under review. Outcome not yet known.
   

• Attorney in Process (Red)
  
  The check failed and entered legal collection. This status freezes financial discounts.

• In Agreement (Gray)
  
  An arrangement exists. Payment may be structured, deferred, or partially agreed upon.
   

These statuses directly impact reports, obligations, and risk exposure.

❌ Rejection Reasons – A Layer of Legal Responsibility

 

A rejected check is never "just failed".

The system enforces 27 predefined, bank-standard rejection reasons, ensuring:
 

• Uniform terminology

• Legal protection

• Banking compliance

• Accurate collection processes
   

Each rejection reason is permanently saved and linked to:
 

• Status

• Notes

• Team member

• Client file
   

This is crucial for legal disputes, audits, and debt collection.
 

- JSON Additional Details – Why It Exists
 

Checks carry non-relational data:
 

• Payee name

• ID number

• Pay to the order of text

• Images

• Associated team members
   

Instead of splitting the schema, all check-specific data is stored within a structured JSON object, providing flexibility while maintaining consistency.
 

This allows for:
 

• Future expansion

• Multiple images

• Multi-member ownership

• Zero schema migrations
   

- Team Member Assignment (Ownership and Responsibility)
 

Each check can be assigned to one or more team members.

This transforms checks from passive records into owned financial tasks.
 

Benefits:
 

• Clear accountability

• Focused visibility

• Reduced errors

• Faster resolution
   

Non-admin users see only checks assigned to them, while administrators maintain full oversight.
 

- Image Management (Proof and Evidence)
 

Each check can store multiple images, such as:
 

• Front / back of a check

• Bank stamp

• Legal notes
   

Images are:
 

• Securely stored

• Displayed in an inline preview

• Viewable in full resolution

• Permanently linked to the check record
   

This makes the module audit-ready at all times and demonstrates proof of payment or failure.
 

✏️ Editing Philosophy (Supervised, Not Free)
 

Check details are editable, but never randomly.
 

Edits update:
 

• Structured JSON fields

• Notes

• Status

• Rejection reasons
   

Every change is intentional and immediately reflected in:
 

• Reports

• Liabilities

• Legal processes
   

There is no "silent correction".
 

- Export and Reporting Integrity
 

Exports include:
 

• Check owner details

• Status

• Rejection reasons

• Associated members

• Notes

• Amounts and currency
   

Exports always:
 

• Respect filters

• Reflect live status

• Maintain legal context
   

This ensures that export data is safe for accountants, lawyers, and auditors.
 

- Security and Access Control
 

The Checks Module enforces:
 

• Organization-level isolation

• Role-based visibility

• Assignment-based access

• Secure deletion with confirmation
   

No user can accidentally:
 

• View unauthorized checks

• Modify unrelated records

• Unintentionally delete checks