Party Ledger, Partial Payments, Credit Sales, Write-Offs and Outstanding Tracking

Wholesale business often runs on relationships. A regular retailer may pay the full invoice immediately, make a partial payment and pay the balance later, or take the complete order on credit. My Local Shops Order Manager records each of these situations without mixing a genuine outstanding amount with a commercially agreed settlement difference.

The result is a practical party outstanding and payment tracking system: the invoice remains the original sales document, payments remain visible as payments, and only money that is truly expected from the customer stays in Outstanding.

Payment and outstanding behaviour at a glance

Real business situation	Order Manager behaviour
Customer pays the exact total	Invoice becomes Paid with zero balance
Customer pays part now	Invoice becomes Partial and only the balance remains due
Customer pays nothing now	Invoice becomes Unpaid/credit and the full total remains due
Customer pays through two modes	Separate payment rows can record modes such as Cash and UPI
Customer pays later	Record another receipt from Invoice Detail
Owner accepts less as final payment	Keep the invoice total, record an agreed settlement adjustment and close the balance
Customer pays slightly extra	Keep the invoice total, record the extra received and close the balance
Staff accidentally leaves an agreed bill partial	Owner can review it and deliberately close the remaining difference later
Owner checks total receivable	Server calculates the exact open-invoice count and sum
Owner wants collection priority	View parties by highest due or invoices from oldest first

The three choices when creating an invoice

Before a new invoice saves, the user must answer one simple question: How was this settled?

1. Paid in full

Choose Paid in full when the parties consider the sale completely settled.

The amount field is prefilled with the invoice total, and the billing user selects the actual payment mode. If the entered amount exactly matches the total, the invoice is saved as Paid and its balance is zero.

If the amount differs from the invoice total, Order Manager does not silently assume that the difference should disappear. It shows the bill total, actual amount received and difference, then requires explicit confirmation.

2. Partial payment

Choose Partial when some money is received and the customer is genuinely expected to pay the rest later.

Example:

• invoice total: ₹50,000;
• received now: ₹20,000; and
• balance due: ₹30,000.

The invoice status becomes Partial. The ₹30,000 appears in Outstanding until later payments or a confirmed settlement close it.

3. Full credit

Choose Full credit when no money is received at invoice creation.

Example:

• invoice total: ₹50,000;
• received now: ₹0; and
• balance due: ₹50,000.

The sale and stock deduction still complete, but the entire invoice appears as outstanding against the selected party.

Payment mode records what actually happened

Order Manager supports the operational modes:

• Cash;
• UPI;
• Card; and
• Bank transfer.

These modes record a receipt; the app does not collect or transfer the money itself.

More than one payment row can be used for the same invoice. For example, a ₹30,000 amount received at sale could be recorded as:

Mode	Amount
Cash	₹10,000
Bank transfer	₹20,000
Total received	₹30,000

Each row remains a separate payment record linked to the invoice and party.

Why invoice total and amount received must remain separate

Consider a wholesale invoice of ₹51,000. The regular customer pays ₹50,000, and both parties agree that the account is complete.

Changing the invoice total to ₹50,000 would misrepresent the actual sale document. Leaving ₹1,000 outstanding would also be wrong because the owner no longer expects to collect it.

Order Manager keeps the meanings separate:

Stored business value	Amount
Original invoice total	₹51,000
Actual amount received	₹50,000
Agreed settlement adjustment	₹1,000
Balance due	₹0
Payment status	Paid

The original invoice remains ₹51,000. The payment history truthfully shows ₹50,000 received. The ₹1,000 is recorded as a confirmed commercial settlement adjustment rather than being hidden as a fake payment or continuing due.

This is sometimes casually called a write-off in day-to-day business, but the application keeps it as an explicit settlement adjustment so the owner and CA can see what happened.

Confirmation prevents accidental payment mismatch

The Paid in full option is a business declaration, not only a mathematical comparison. Therefore a mismatch requires deliberate confirmation.

For the ₹51,000 invoice and ₹50,000 receipt, the confirmation explains:

• bill total;
• amount received;
• difference; and
• that the difference will not appear as outstanding.

The user can go back or explicitly accept ₹50,000 as full payment. Nothing is silently removed.

This protects two common cases:

• a genuine negotiated final settlement; and
• an accidental typing mistake where the user actually intended Partial.

What if the customer pays more than the invoice?

Suppose the invoice is ₹995 and the customer gives ₹1,000.

If the extra ₹5 is actually kept, Order Manager can store:

Stored business value	Amount
Invoice total	₹995
Amount received	₹1,000
Settlement excess	₹5
Balance due	₹0
Payment status	Paid

The confirmation specifically asks the user to accept the extra amount only if it was really retained. This prevents an accidental over-entry from silently changing business results.

In most real invoices the prefilled exact amount avoids this situation, but the data model remains truthful when it occurs.

Record a payment after the invoice date

Open Invoice Detail and choose Record payment for an invoice with a balance. The screen shows the current amount due and lets the user enter the new receipt and payment mode.

Example:

Event	Received	Balance after event
Invoice created for ₹50,000 on full credit	₹0	₹50,000
First bank payment	₹20,000	₹30,000
Second UPI payment	₹15,000	₹15,000
Final cash payment	₹15,000	₹0

When the final payment covers the balance, the invoice automatically becomes Paid and leaves Outstanding.

A receipt larger than the current due can also be recorded, but any excess remains explicit. A receipt smaller than the due remains Partial unless the seller deliberately chooses to accept it as the final settlement.

Closing a smaller final payment later

The same agreed-settlement behaviour is available during later collection.

Suppose an invoice currently has ₹15,000 due. The customer pays ₹14,500 and the owner agrees that nothing more will be collected.

The owner can choose to pay the remaining balance in full, enter ₹14,500, and confirm the ₹500 difference. The system then stores:

• the new ₹14,500 receipt;
• a ₹500 settlement adjustment;
• zero balance due; and
• Paid status.

If the owner does not confirm the difference, the invoice stays open with the real remaining balance.

When staff marks an agreed payment as Partial

Staff may not know the owner's commercial agreement. A staff member might reasonably see a ₹51,000 bill and ₹50,000 received, then choose Partial because the numbers do not match.

That is safer than silently closing the difference. Later, the owner can open the invoice, confirm that ₹50,000 was the agreed final amount, and choose Close agreed difference.

Only the owner can perform this owner-correction settlement. The operation:

• reads the latest balance again;
• records who confirmed it and when;
• adds the open remainder to the settlement adjustment;
• keeps the invoice and GST values unchanged; and
• changes the live balance to zero.

This means staff can record facts conservatively while the owner retains control over commercial write-offs.

What appears in Outstanding?

Outstanding contains only invoices whose payment status is:

• Unpaid; or
• Partial.

Paid invoices are not downloaded and then filtered into the outstanding worklist. The server query requests open statuses directly.

The total header is calculated using a server-side count and sum of balanceDue. This provides the exact total receivable and open-invoice count without downloading every matching invoice merely to add the numbers on the phone.

The operational list remains bounded for sensible app performance. Pull to refresh is available when the owner wants to reconcile it with the latest server state.

Party view and invoice view serve different jobs

The Outstanding screen has two views.

Party view

Party view groups open invoices under each customer and sorts the visible parties by highest total due first.

Use this when the owner asks:

Payment kis party se lena hai?

Each party row shows the combined due, number of open invoices and oldest open date. Opening it shows that party's open invoices from oldest first along with contact information.

Invoice view

Invoice view shows individual open bills oldest first.

Use this when the owner wants to follow up on the oldest unpaid sale regardless of which party it belongs to.

Every invoice can be opened to view details, record payment or review its settlement.

The party page keeps the relationship together

The Parties tab is the business directory for the seller's own customers. A party record may contain:

• name;
• mobile number;
• billing address;
• state and pincode;
• GSTIN where applicable; and
• additional delivery addresses.

From Party Detail, the owner can review invoices, credit notes and current outstanding associated with that customer. The seller can search their own party records by name, mobile number or GSTIN.

Removing a party from the active list does not delete historical invoices. Past business documents remain linked for audit and reporting.

No seller can browse another subscriber's party records. Party queries are scoped to the authenticated seller, and authorised staff work under their assigned seller relationship.

Outstanding changes immediately after payment

Order Manager keeps an in-memory outstanding snapshot so repeatedly opening Home, Outstanding and a party's dues does not cause the same Firestore reads every time.

After a successful payment or agreed settlement:

• the affected invoice balance is patched in memory;
• the exact total due is adjusted;
• a fully paid invoice is removed from the open list; and
• the visible screens update without a complete re-download.

Pull to refresh remains available for changes made from another device. This balances Firebase cost, speed and data freshness for a wholesale business with relatively few daily invoices.

Truthful profit after an agreed difference

The invoice's product profit is first calculated from:

taxable selling value before GST − snapshotted landed cost

An agreed settlement difference then changes what the owner actually realised.

Using the ₹51,000 invoice example, assume:

• taxable sale value before GST: ₹51,000;
• landed cost: ₹40,000;
• invoice profit before settlement: ₹11,000;
• amount accepted as full payment: ₹50,000; and
• settlement adjustment: ₹1,000.

The realised profit becomes:

₹11,000 − ₹1,000 = ₹10,000

The sales invoice still reports ₹51,000. The owner report separately shows the settlement adjustment, preventing the owner from believing the uncollected ₹1,000 was profit.

If an extra amount was accepted, settlement excess is added to realised profit instead of being hidden.

GST itself is never counted as profit.

Month-end review before CA reports

Before generating the CA files for a completed month, Order Manager checks for invoices from that month that are still Unpaid or Partial.

The owner can:

• review the pending invoices;
• open an invoice detail page;
• record a real payment;
• keep the balance pending; or
• close an agreed difference when that is what actually happened.

The review is actionable rather than only a warning. It gives the owner a chance to correct staff confusion before freezing the month-end report.

The owner may still choose to generate the report with genuine outstanding invoices. A business can legally have receivables; the purpose of the review is to prevent avoidable recording mistakes.

The CA exports preserve:

• original invoice totals;
• actual amount paid;
• balance due and payment status;
• settlement adjustments;
• settlement excess; and
• applicable GST and non-GST classifications.

These records organise the business truth for review. My Local Shops does not file tax returns or decide the accounting treatment on behalf of the owner or CA.

Credit notes are not payment receipts

When goods are returned, the correct tool is a linked credit note rather than a fake payment or manual reduction of the original invoice.

A credit note can affect stock, credited value, tax values and the remaining balance according to the recorded return. Payment receipts, settlement adjustments and credit notes therefore remain separate business events.

This distinction helps the owner answer three different questions:

1. How much was sold?
2. How much money was received?
3. How much was reduced because of a return or agreed settlement?

Practical examples

Exact full payment

Invoice ₹25,000, received ₹25,000 by bank transfer:

• amount paid: ₹25,000;
• balance: ₹0; and
• status: Paid.

Partial payment

Invoice ₹25,000, received ₹10,000 by UPI:

• amount paid: ₹10,000;
• balance: ₹15,000; and
• status: Partial.

Full credit

Invoice ₹25,000, received nothing:

• amount paid: ₹0;
• balance: ₹25,000; and
• status: Unpaid.

Agreed reduction

Invoice ₹25,000, received ₹24,000 and accepted as final:

• amount paid: ₹24,000;
• settlement adjustment: ₹1,000;
• balance: ₹0; and
• status: Paid.

Mixed payment

Invoice ₹25,000, received ₹5,000 cash and ₹20,000 by bank transfer:

• two payment records;
• total amount paid: ₹25,000;
• balance: ₹0; and
• status: Paid.

What not to do

For clean records, avoid these shortcuts:

• do not reduce the original invoice total only to hide a payment difference;
• do not record money that was never received as a fake payment;
• do not close a genuine balance merely to make Outstanding look clean;
• do not use a payment to represent returned goods; and
• do not leave an agreed final settlement marked Partial forever.

Use the event that matches reality: payment, outstanding balance, settlement adjustment or credit note.

Frequently asked questions

Does Paid in full always require the exact invoice amount?

No. Exact payment is the default, but a different final amount can be accepted only after explicit confirmation. The difference remains recorded.

Does a partial payment change the invoice total?

No. It changes the amount paid and balance due, not the original invoice value.

Can a payment be recorded through more than one mode?

Yes. Multiple payment rows can record combinations such as Cash plus UPI or Cash plus Bank transfer.

Can I record a payment later?

Yes. Open an invoice with a balance and use Record payment.

What happens when the final payment is less than the balance?

It remains Partial unless the owner or authorised billing flow deliberately confirms that the smaller receipt is the final settlement.

Can staff close an agreed outstanding difference later?

The dedicated owner-correction action is owner-only. Staff can conservatively record the payment and leave the remaining balance for owner review.

Will a settled difference appear as outstanding?

No. Its balance becomes zero and it leaves the open-invoice query, while the adjustment remains visible in reports.

Is the outstanding total calculated from only the visible cards?

No. The exact header uses a server-side count and sum across matching open invoices. The worklist itself is bounded for usability.

Does deleting a party delete old invoices?

No. Removing the party hides it from the active directory; historical invoices remain linked.

Does Order Manager automatically collect payment from the customer?

No. It records payments that happened through the selected real-world mode.

Does an agreed reduction reduce GST on the original invoice?

No. A commercial settlement adjustment does not rewrite the invoice or its GST values. The owner and CA should review the recorded adjustment separately.

Continue with payments and reports

• View and download Order Manager
• Read the complete Order Manager guide
• Learn GST and non-GST multi-variant billing
• Understand the connected purchase-to-report workflow
• Compare current plans

The next guide will explain owner reports, CA files, GST/non-GST separation and month-end review in seconds.