# Infor LN: finalize run fails or gets stuck > Source: https://netray.co/erp-help/ln-finalize-run-error-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Finalize sessions such as Cost Price Calculation, Sales Invoicing, and Period-End Statistics run as a broadly locked, largely exclusive batch step, so they most often fail because another user has the module open, a prior finalize run did not close cleanly, or a specific record has bad master data. Read the finalize log for the exact record or reason code, not just the failure message. ## Kind error ## System infor-ln ## Erp Infor LN (Baan) ## Module Finance / Finalization Processing ## Query Finalize run fails or gets stuck in Infor LN (Cost Price Calculation, Sales Invoicing, Statistics) ## Alternate Queries - LN finalize session says session is in use - Infor LN cost price calculation finalize error - LN sales invoicing finalize stuck - LN period-end finalization failed ## Applies To Infor LN 10.x, Cost Price Calculation, Sales Invoicing, Statistics finalization ## Steps ### Recover a failed or stuck finalize run **Items:** - Read the finalize log or message list for the specific record or reason code it stopped on - Confirm no other user has an editing session open in the same module, since finalize typically needs broad exclusive access - Check Active Sessions for a previous finalize run still shown as running that did not close properly - If a prior run is orphaned, confirm with an admin that it truly finished (check the target tables or output) before terminating it - Fix the flagged data error, such as an item without a valid cost component or an order line missing a required field - Re-run finalize for just the affected scope if the session supports a partial or selective run - Otherwise re-run during a maintenance window if the process needs true exclusive access across the company - Confirm no integration or BOD process is concurrently touching the same tables during the finalize window - Validate the results against a known-good prior period or run before downstream reports and postings consume them ## Sections ### Why finalize needs exclusivity **Body:** Finalize processes recalculate and post totals - cost components, invoice amounts, statistical balances - that other transactions read afterward. LN restricts concurrent activity during these runs to guarantee the numbers are consistent across the whole set rather than reflecting a half-updated state, which is why the lock is broader than a single record. ### Common failure reasons **Body:** The recurring causes are: another user still has the module open interactively, a previous finalize run did not close cleanly and is still shown as active, a specific item or order has master data that fails a validation the finalize step performs, or a concurrent integration job is touching the same tables. ### Recovering from a stuck run **Body:** Before terminating anything, check whether the prior run genuinely finished by looking at its output or target tables rather than trusting the session status alone. A run that failed cleanly typically rolls back; one that partially committed needs more careful review before you re-run, to avoid double-posting. ### Scheduling to avoid repeat failures **Body:** Running finalize in a dedicated window, coordinating the schedule with EDI or BOD jobs that touch the same tables, and asking users to log out of the affected module beforehand prevents most of these failures from recurring month after month. ## Pitfalls - Re-running finalize immediately without checking why the first attempt failed, which can mask a real data problem - Terminating a prior run that looks stuck but is actually still legitimately processing a very large data set - Running finalize concurrently with a scheduled BOD or EDI job touching the same tables - Ignoring warning-level messages in the log that predict the next failure - Not validating totals after a recovered run before downstream reports or postings consume them ## Ai Angle ERPray can check Active Sessions and recent finalize run history in one query, telling an admin whether a stuck run is a genuinely long-running process or an orphaned session worth terminating, instead of the admin cross-referencing timestamps and logs by hand before every decision. ## Faq ### Can I just kill a stuck finalize session and re-run it? **Answer:** Only after confirming it did not partially commit. Check the target tables or output first. If it truly rolled back cleanly, terminating and re-running is safe; if it partially posted, you risk double-counting on the next run. ### Why does finalize fail on one item but not the whole run? **Answer:** Many finalize processes validate every record in scope and stop or skip on the first one that fails a check, such as a missing cost component. Fixing that specific record and re-running the same scope usually resolves it. ### Does finalize really need every user out of the module? **Answer:** For most finalize processes, yes for the tables it recalculates, since it needs a consistent snapshot to post correct totals. Check the specific session's documentation for whether it needs full exclusivity or just avoids conflicting edits. ### Can integration jobs cause a finalize failure? **Answer:** Yes. A BOD or EDI process writing to the same tables during a finalize window can trigger the same locking or data-consistency failures as an interactive user, so schedules should be coordinated to avoid overlap. ## Search terms infor ln finalize run failed, ln cost price calculation finalize error, ln sales invoicing finalize stuck, infor ln period end finalization, ln finalize session in use error, baan finalize run recovery, ln statistics finalize error, infor ln finalize exclusive access --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json