> 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. This release also corrects the party details shown for accounts that have both customer and supplier details and the GR details shown for some sale bills. *** ### **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. *** ### **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. --- # 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.