> For the complete documentation index, see [llms.txt](https://kb.logicerp.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.logicerp.com/logic-erp-version-release-notes/october-2026/reports-queries/financial-report/dues-ageing-analysis-new.md). # Dues/Ageing Analysis - New Logic ERP has updated the **Dues/Ageing Analysis - New** report. Overdue days and discount days can now be counted from the **GR / LR date** entered on the bill, so a bill is aged from the day the goods were dispatched or received rather than from the bill date. The **MSME TYPE** column now shows the MSME type recorded for the party for that financial year. If no type is recorded for that year, it shows the type from the party master. A new **CUSTOMER NAME** column shows the customer entered on each sale bill. This release also corrects the party details shown for accounts that have both customer and supplier details, the GR details shown for some sale bills, and the GR details shown for bills brought forward from earlier years. *** ### **Step 1: Open the Report** * Navigate to **Reports/Queries** and select **Financial Reports**. * Open the **Dues/Ageing Analysis - New**. *** ### **Step 2: Ageing from the GR / LR date** * Go to **Configuration > Report Options-1**. Two options decide which date the days are counted from. * **Overdue Analysis on** now has a third choice: * **Due Date**: overdue days are counted from the due date (as before). * **Bill Date**: overdue days are counted from the bill date (as before). * **GR/LR Date**: overdue days are counted from the GR / LR date entered on the bill. This is new. * **Discount Calculation on** is a new option: * **Bill Date**: discount days are counted from the bill date. This is how the report has always worked, and saved configurations stay on this choice. * **Due Date**: discount days are counted from the due date. * **GR/LR Date**: discount days are counted from the GR / LR date entered on the bill. * The GR / LR date is taken from sale bills and sale returns, purchase bills and purchase returns, and journal vouchers. * For pending bills, the days are counted up to the report's end date. For payment analysis, they are counted up to the receipt date. * With **Overdue Analysis on** set to **GR/LR Date**, these follow the GR / LR date: **DAY OVERDUE**, **AMOUNT IN TIME**, **AMOUNT OVERDUE**, **CURRENT AMOUNT**, **OVER DUE AMOUNT**, and the ageing day columns (for example **0 To 30**). When the report is run for one **Ageing Days** range, the bills kept in the report are picked on the same basis. * With **Discount Calculation on** set to **GR/LR Date**, **DISCOUNT(%)** and **DISCOUNT AMOUNT** follow the GR / LR date. * The GR / LR date is usually later than the bill date, so a bill shows fewer overdue days and may move to a younger ageing column. More bills may fall inside a discount period. Amounts can also move from **AMOUNT OVERDUE** / **OVER DUE AMOUNT** to **AMOUNT IN TIME**, and **INTEREST AMOUNT** can fall. This is intended. * A bill uses its bill date instead when: * no GR / LR date is entered on it, or * its GR / LR date is after the report's end date (the goods had not been received by then). * When either option is set to **GR/LR Date**, the **G.R. DATE** column also shows the GR / LR date of purchase bills and purchase returns, so you can see the GR / LR date entered on them. Earlier this column was blank for purchases. * Interest is still counted from the date set in **Int. Calculation on**, but it is charged only on the overdue amount, so a bill not yet overdue from its GR / LR date may show less interest or none. * If **Grace Days** and **Grace Days Over Due Limit** are both set, the overdue days checked against the limit also follow the GR / LR date. * **DUE DATE** and **DAY OVERDUE FROM BILL DATE** do not change. *** ### **Step 3: MSME TYPE column** * Add the **MSME TYPE** column from the report's column settings. * For each entry, the report works out the financial year from the document date. It then shows the MSME type recorded for the party for that year: **Micro**, **Small**, **Medium** or **None**. * If no MSME type is recorded for the party for that year, the column shows the MSME type from the party master, as before. * One party can show different MSME types on different rows. For example, a bill brought forward from last year shows last year's type. This is intended. * **MSME NO.** and **MSME CATEGORY** still come from the party master. *** ### **Step 4: CUSTOMER NAME column** * Add the **CUSTOMER NAME** column from the report's column settings, then tick it. * For each sale bill and sale return, it shows the **Customer Name** entered on the bill. * **PARTY NAME** still shows the account the bill is posted to. When an **A/c Entry Customer** is entered on the bill, **PARTY NAME** shows the A/c Entry Customer and **CUSTOMER NAME** shows the customer the bill belongs to. This helps with location-wise and agent-wise payment follow-up. * Bills brought forward from earlier years show the customer of that bill. * Rows that are not a sale bill or sale return show the party name in this column. These are receipts, journal vouchers, debit and credit notes, purchase bills, and opening balances that have no bill. * The report's grouping and totals stay by **PARTY NAME**. > **Example — one A/c Entry Customer for two branches of a customer** > > Two bills are entered for **Sharma Traders - Pune** and **Sharma Traders - Nashik**, both with the A/c Entry Customer **Sharma Traders - Head Office**. Both bills show **Sharma Traders - Head Office** under **PARTY NAME**. **CUSTOMER NAME** shows **Sharma Traders - Pune** on the first bill and **Sharma Traders - Nashik** on the second. *** ### **What's corrected** * An account that has both customer details and supplier details now shows one set of party details. A supplier account takes its supplier details. Every other account takes its customer details. * A sale bill or sale return with no transport selected now shows its GR details. Earlier, **G.R. DATE**, **G.R. NO.**, **SL REMARKS-1**, **SL REMARKS-2**, **SL REMARKS-3** and **PARTY ORDER NO.** were blank for such bills. These columns can now show values where they were blank before. This is intended. * For bills brought forward from earlier years, **G.R. DATE**, **G.R. NO.**, **SL REMARKS-1**, **SL REMARKS-2**, **SL REMARKS-3**, **PARTY ORDER NO.**, **TRANSPORT NAME**, **JOURNAL VOUCHER DATE**, **JOURNAL VOUCHER NO.** and **JV DOCUMENT NO.** now come from that bill. Earlier they could be blank, or show the details of a different bill with the same bill number from another year. Overdue and discount days counted from the GR / LR date use the corrected date too. Bills of the current year show the same as before. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://kb.logicerp.com/logic-erp-version-release-notes/october-2026/reports-queries/financial-report/dues-ageing-analysis-new.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.