Customization broken the integrity between GL and Subledgers (AR,AP and IN)

@Kisho AJ if the customization changed only Batch.CuryID, and Batch.CuryInfoID still points at a CurrencyInfo row with the document's currency and rate, your balances are intact. Posting builds account history from the GL line amounts and each account's own currency, without reading Batch.CuryID. GLTran has no currency column either; each line gets its currency through CuryInfoID. So the header alone doesn't break the base-currency tie-out between GL and AR, AP and IN.

Confirm that before anything else. Join Batch to CurrencyInfo on CompanyID and CuryInfoID and list the rows where the two CuryIDs differ. On our demo database that list comes back empty across about 43,000 batches. Compare at the header, not the lines. Some foreign-currency AR batches in the demo data have a rounding line with a base-currency CurrencyInfo, so a line-level comparison flags batches that are fine. A batch you know is wrong that doesn't show up in the list has the wrong currency on its CurrencyInfo row too. That's more than a header problem, and I'd check its line amounts against the source documents before any update.

GL301000 shows Batch.CuryID, and the GL Register and GL Edit Detailed reports use it to decide whether to print foreign amounts. Reverse Batch copies the original header, so fix these before anyone reverses one. If you use project multi-currency, check the project transactions from those batches too. They take their currency from Batch.CuryID when the batch is saved, and the amount conversion depends on it.

If Generate Consolidated Batches is on in General Ledger Preferences, release adds documents to a batch it already created by matching Batch.CuryID, branch and period. Check which documents landed in each damaged batch before you touch the header. Fix the customization first so it stops producing bad batches. Back up, and run the update on a copy before production. For each batch it's one column: set Batch.CuryID to the CurrencyInfo.CuryID it points at.

The code and reports behind this are the same in 25 R1, 25 R2 and 26 R2.