My Local Shops logoMy Local Shops.in
How to Record Payments and Correct an Invoice's Settlement Status
Order Manager

How to Record Payments and Correct an Invoice's Settlement Status

Learn how paid-in-full, partial and credit invoices work, how to record later receipts in multiple modes, and how an owner closes an agreed pending difference without changing the bill or GST value.

A wholesale invoice and the money received against it are related, but they are not the same record. A ₹51,000 bill may be paid exactly, paid in several modes, paid partly today, kept fully on credit, or commercially settled at ₹50,000 when both parties agree that nothing more is due.

My Local Shops keeps the original invoice amount unchanged while recording what was actually received. This allows Order Manager and Staff Bill to show real outstanding, preserve GST values, and distinguish ordinary payments from an explicitly accepted settlement difference.

This guide explains the complete payment workflow at invoice creation, later collection, and owner month-end correction.

The values the system keeps separately

Understanding these fields makes every scenario simpler.

ValueMeaning
Grand totalFinal invoice value after tax and round-off
Amount paidTotal money actually recorded as received
Settlement adjustmentShortfall deliberately accepted as no longer collectible
Extra receivedAmount deliberately retained above the remaining bill value
CreditedValue reversed through linked credit notes
RefundedMoney returned after credit notes
Balance dueAmount that should still appear as outstanding
Payment statuspaid, partial or unpaid based on the final balance

The simplified balance is:

Grand total − paid − credited − accepted settlement adjustment + refunded

The result is kept at paise precision and cannot fall below zero or exceed the original invoice total.

Choose payment status while creating an invoice

After reviewing a new invoice, Order Manager or Staff Bill asks How was this settled? The user must choose one of three options.

Paid in full

Choose this when both sides agree that the sale is complete and no money should remain outstanding.

The payment amount is prefilled with the invoice total, but the user can enter the amount actually received. If the total differs from the invoice value, the app does not silently accept it. A confirmation dialog explains the invoice total, received amount and difference.

Partial payment

Choose this when some money is received now and the rest genuinely remains payable.

The sheet shows the received total and remaining balance. After saving, the invoice appears as partial and remains in outstanding.

Full credit

Choose this when nothing is received at invoice creation—commonly called udhaar.

No payment row is created. The entire invoice balance remains due, and payment can be recorded later from Invoice Detail.

Record one payment or several payment modes

A customer may pay using more than one method. The Payments section allows additional rows, each with its own amount and mode.

Supported modes are:

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

Example for a ₹50,000 invoice:

Payment modeAmount
Cash₹20,000
Bank transfer₹30,000
Total received₹50,000

The invoice stores ₹50,000 as total amount paid, while two separate receipt records preserve how the money arrived.

Each payment record is linked to the seller, party, invoice and invoice number. This supports payment history without turning a mixed payment into one misleading mode.

Scenario 1: exact full payment

Suppose:

  • invoice grand total: ₹51,000;
  • amount received: ₹51,000; and
  • choice: Paid in full.

The system stores:

FieldValue
Grand total₹51,000
Amount paid₹51,000
Settlement adjustment₹0
Extra received₹0
Balance due₹0
Payment statusPaid

The bill, payment and outstanding all match exactly.

Scenario 2: partial payment with real outstanding

Suppose:

  • invoice grand total: ₹51,000;
  • amount received now: ₹20,000; and
  • choice: Partial payment.

The result is:

FieldValue
Grand total₹51,000
Amount paid₹20,000
Balance due₹31,000
Payment statusPartial

The ₹31,000 remains visible in Outstanding and Party Detail. It is not treated as a discount or loss because the seller has said that payment is still expected.

Scenario 3: full credit sale

Suppose:

  • invoice grand total: ₹51,000;
  • amount received: ₹0; and
  • choice: Full credit.

The result is:

FieldValue
Amount paid₹0
Balance due₹51,000
Payment statusUnpaid

The invoice remains a valid completed sale. “Unpaid” describes its collection status; it does not mean that invoice creation failed.

Scenario 4: customer pays less but both sides close the sale

This is common in wholesale relationships. The invoice may legally and commercially remain ₹51,000, while the owner agrees to accept ₹50,000 as final payment.

The user selects Paid in full and changes the received amount to ₹50,000. The app shows:

  • Bill total: ₹51,000;
  • Received: ₹50,000;
  • Difference: ₹1,000; and
  • a warning that this difference will be closed and will not appear as outstanding.

Only after the user chooses Accept ₹50,000 as full payment does the system store:

FieldValue
Grand total₹51,000
Amount paid₹50,000
Settlement adjustment₹1,000
Balance due₹0
Payment statusPaid
Settlement typeAgreed reduction

The ₹1,000 is neither hidden nor shown as collectible. It remains an explicit settlement adjustment.

Why the invoice and GST value stay ₹51,000

An accepted payment difference is not the same as changing item prices after the invoice has been issued.

The original invoice still represents:

  • products and quantities sold;
  • taxable value;
  • CGST and SGST or IGST;
  • grand total; and
  • buyer-facing bill history.

The settlement records a later money outcome. It does not rewrite the GST invoice down to ₹50,000 or remove ₹1,000 from the original bill.

For a taxable supply, the seller should follow their accountant's advice on any formal tax adjustment required. The settlement field is an operational payment record, not a replacement for a credit note where goods or taxable value genuinely need reversal.

How the accepted difference affects owner profit

Invoice-level product profit begins with sales before GST minus snapshotted cost of goods.

The owner report then separates commercial settlement effects:

Realized profit = invoice profit − settlement adjustments + extra received

Example:

  • sales before GST: ₹48,571;
  • cost: ₹40,000;
  • invoice profit: ₹8,571;
  • accepted settlement reduction: ₹1,000.

Realized profit becomes ₹7,571.

This is more honest than either of these incorrect alternatives:

  • claiming profit based on money that the owner agreed never to collect; or
  • changing the tax invoice itself merely to make payment equal the bill.

The invoice detail shows the settlement adjustment and who confirmed it when identity information is available.

Scenario 5: customer pays more than the remaining amount

Overpayment is rare, but the system does not silently convert it into a negative outstanding.

Suppose:

  • amount due: ₹995;
  • amount entered: ₹1,000.

The app shows an Extra amount received confirmation with the ₹5 difference. Confirm only when the business actually retained that extra money.

After confirmation:

FieldValue
Amount applied as receipt₹1,000
Balance due₹0
Extra received₹5
Settlement typeRounded up

The owner report can add the explicit extra to realized profit instead of hiding it as an arithmetic accident.

If the extra was not really kept—for example, staff returned ₹5 cash—record the actual retained amount instead.

Partial choice automatically closes when the entered amount covers the bill

A billing user may select Partial payment and then enter an amount equal to or greater than the invoice total.

The system does not leave an impossible “partial” status with zero balance. It converts the result to paid in full. If the entered amount is above the bill, the extra-amount confirmation still appears.

This protects the status from the label the user first tapped and bases the final result on the money entered.

Record a later payment from Invoice Detail

An unpaid or partial invoice shows:

Record payment · ₹X due

Open it to choose:

  • Pay remaining in full; or
  • Partial payment.

Full credit is not shown in this later-payment sheet because the invoice is already open and choosing “receive nothing” would create no new event.

Later partial-payment example

Starting position:

  • invoice total: ₹51,000;
  • already paid: ₹20,000;
  • balance due: ₹31,000.

Record a later bank transfer of ₹10,000 as Partial payment.

New result:

  • total amount paid: ₹30,000;
  • balance due: ₹21,000; and
  • status remains Partial.

The new ₹10,000 receipt appears in payment history with its mode and date.

Later final-payment example

Starting balance is ₹21,000. Choose Pay remaining in full and record ₹21,000.

The invoice becomes paid with zero due and no settlement adjustment.

Closing a smaller final payment later

Suppose ₹21,000 is due, but both parties agree that ₹20,500 is the final collection.

Choose Pay remaining in full, enter ₹20,500 and confirm the ₹500 difference. The system:

  • records ₹20,500 as money actually received;
  • adds ₹500 to settlement adjustment;
  • closes balance due to zero; and
  • marks the invoice paid.

Choosing Partial payment instead would correctly leave ₹500 outstanding. The difference depends on the commercial decision, not merely the entered amount.

Correct a mistaken partial status during owner review

Staff may sometimes mark a commercially settled bill as partial because they understand “paid in full” to mean the exact printed amount. The owner may later find that invoice in Outstanding and confirm that both sides had already agreed no more money was due.

Before finalising a monthly CA report, Order Manager provides Review pending bills. Opening an invoice in this process gives the owner three actions:

  1. Record payment — money was actually received but not recorded;
  2. Still pending — the party genuinely still owes the balance; or
  3. Agreed as complete — both parties had already closed the amount and no new payment occurred.

Agreed as complete example

  • invoice total: ₹51,000;
  • recorded paid: ₹50,000;
  • current balance due: ₹1,000;
  • owner confirms no more money is payable.

Order Manager shows the bill, amount received and pending amount, and warns:

Choose this only when both sides agreed that no more money is due. The bill and GST value will remain unchanged.

After confirmation:

  • no fake ₹1,000 payment is created;
  • settlement adjustment increases by ₹1,000;
  • balance due becomes zero;
  • payment status becomes paid;
  • settlement type records an owner correction; and
  • confirmer identity and time are stored.

This is an owner-only correction. The service verifies that the confirming authentication UID is the seller ID.

Owner correction is not a payment

Do not choose Agreed as complete when the customer actually handed over money that is missing from the system. Use Record payment in that case.

The distinction affects reports:

Real eventCorrect action
Customer paid ₹1,000 laterRecord a ₹1,000 payment
Customer still owes ₹1,000Keep Still pending
Both parties agreed to close ₹1,000 without paymentAgreed as complete

Creating a false receipt would overstate cash or bank collection. Leaving an agreed difference pending would overstate receivables. The explicit owner correction avoids both mistakes.

What appears in Outstanding

Outstanding uses the invoice's saved paymentStatus and balanceDue.

  • Full credit invoices appear as unpaid.
  • Partially collected invoices appear as partial.
  • Exact full payments do not appear.
  • Confirmed agreed settlements do not appear because balance is zero.
  • Credit notes may reduce or eliminate the remaining due.

The system queries only invoices whose status is unpaid or partial instead of downloading all invoices and checking them on the phone.

This keeps Firestore reads aligned with the list the owner actually needs to review.

Payment history remains linked to the invoice

Invoice Detail shows recorded receipt rows with amount, mode and date. The invoice summary separately shows:

  • grand total;
  • paid;
  • credited;
  • refunded;
  • settlement adjustment;
  • extra received; and
  • balance due.

Keeping the receipt rows separate makes multipart and later payments understandable, while the totals provide a quick current position.

Order Manager and Staff Bill responsibilities

Both apps can record payment during invoice creation and later collection. Staff Bill records invoices and receipts under the linked owner's seller account while preserving the staff creator identity where relevant.

The owner retains broader review capabilities in Order Manager:

  • complete outstanding across the business;
  • party-level receivables;
  • invoice profit and realized settlement effect;
  • month-end pending-invoice review; and
  • owner-only Agreed as complete correction.

Staff should record what happened at the billing counter. The owner should review exceptional settlement decisions before accounting reports are finalised.

GST invoice versus payment record

Payment mode does not determine whether a bill is GST or non-GST. Cash, UPI, card and bank transfer can be recorded against either type.

Likewise:

  • partial payment does not reduce taxable invoice value;
  • full credit does not cancel the sale;
  • agreed settlement does not automatically create a tax credit note; and
  • a genuine goods return follows the separate returns and credit-notes workflow.

This separation lets the accountant see the invoice as issued while the owner sees the real collection outcome.

Practical payment checklist

  • Confirm the invoice grand total.
  • Ask how much was actually received now.
  • Add separate rows for different payment modes.
  • Use Partial only when the remaining amount is genuinely collectible.
  • Use Full credit when nothing was received at invoice creation.
  • Confirm any paid-in-full difference deliberately.
  • Do not record an imaginary payment to close a negotiated difference.
  • Review payment rows and balance in Invoice Detail.
  • Record later receipts when they arrive.
  • Before the CA report, let the owner review remaining bills and choose payment, pending or agreed complete accurately.

Frequently asked questions

Can a customer pay partly in cash and partly by bank transfer?

Yes. Add separate payment rows and modes before confirming.

Does Paid in full require the exact invoice amount?

No. A different amount requires an explicit confirmation, after which the difference is tracked as an agreed reduction or extra received.

Does a negotiated reduction change the GST invoice total?

No. The invoice and GST values remain unchanged. The difference is stored separately as a settlement adjustment.

Will an agreed difference appear in outstanding?

No. Once explicitly accepted as full settlement, balance due becomes zero.

Can I record a payment later?

Yes. Open an unpaid or partial invoice and use Record payment.

Can I leave a later payment on full credit again?

There is no need. If nothing new was received, make no payment entry and leave the existing balance pending.

What if the user chooses Partial but enters the full amount?

The final result becomes paid rather than leaving a partial status with zero balance.

Can staff close an invoice while recording an agreed final collection?

The payment sheet supports an explicitly confirmed final settlement. The separate Agreed as complete correction in month-end review is restricted to the owner.

How does settlement affect profit?

The owner report subtracts accepted shortfalls and adds explicitly retained extra amounts when calculating realized profit.

Should an owner review pending invoices before the CA report?

Yes. That review catches missing receipts, genuinely pending bills and commercially completed invoices that were mistakenly left partial.

Record reality without rewriting history

My Local Shops separates the invoice, money received, outstanding and settlement decision. That allows a wholesaler to record exact payment, partial collection, full credit, multipart payment and negotiated completion without changing the products or GST value on the original bill.

The result is useful to both sides of the business: staff can record what happened at the counter, while the owner can see what was collected, what is still due and what was deliberately accepted as closed.

#wholesale payment tracking#partial payment invoice#full credit invoice#party outstanding app#invoice settlement adjustment#record later payment#garment wholesaler payments#Staff Bill payment