Float and Currency Field Precision Issue in ERPNext (Out of Range Value for Large Amounts)

Float and Currency Field Precision Issue in ERPNext (Out of Range Value for Large Amounts)

Hi Everyone,

I am facing a critical issue in ERPNext when posting very large accounting entries, particularly in ERPNext documents such as:

  • Journal Entry

  • Period Closing Voucher

  • GL Entry

  • Payment Ledger Entry

  • Account Closing Entry

Issue Description

When the transaction amount exceeds 12 digits before the decimal point, ERPNext throws an “Out of Range Value” error.

After investigating, I found that many Float and Currency fields in ERPNext are stored in the database as:

DECIMAL(21,9)

This means:

  • Total precision = 21 digits

  • Decimal places = 9 digits

  • Maximum digits before decimal = 12 digits

For example:

999999999999.999999999

Any value larger than this causes the database error.

Temporary Workaround

I manually updated the database field definitions to:

DECIMAL(30,9)

This increases the maximum digits before the decimal point from 12 to 21 digits.

After applying this change, large-value Journal Entries and Period Closing Vouchers were created successfully.

Main Problem

The issue is that after running:

bench migrate

or restarting the server, Frappe Framework automatically resets the fields back to:

DECIMAL(21,9)

As a result, the problem reappears.

Questions

  1. Is there any framework-level configuration to permanently increase Float/Currency field precision?

  2. Why does Frappe enforce DECIMAL(21,9) for these fields?

  3. What is the recommended approach for organizations dealing with extremely large accounting values?

  4. Can this be customized through hooks, patches, or core settings without being overwritten during migration?

Current Understanding

It appears that Frappe internally defines the SQL precision for Float and Currency fields, and schema synchronization during migration restores the default specification.

Request for Guidance

Has anyone faced this issue before? I would appreciate any suggestions for a permanent and framework-supported solution.

Thank you!