American Date Format only??
under review
D
Dan Harell
Go-High-Level is a global platform why is it not possible to use another date format other than the American one?? the rest of the world (all 6.75 bn of us) use dd/mm/yyyy and you only allow mm/dd/yyyy on your invoicing... a bit strange...
Log In
T
Tom Keyser
Measured this on a live sub-account last week, in case the detail helps move it along.
I set one account through four platform languages with matching currencies and created the same invoice in each:
Spanish · MXN 11 de septiembre de 2026 MX$4,526.87
German · EUR 11. September 2026 €4,526.87 (German writes 4.526,87 €)
Swedish · SEK 11 september 2026 kr4,526.87 (Swedish writes 4 526,87 kr)
English · CZK September 11, 2026 Kč4,526.87 (Czech writes 4 526,87 Kč)
The dates on the customer-facing invoice do localise — that part works well. The amounts never do: every locale gets American grouping and decimals with its own currency symbol moved to the front.
In the invoice app's client-side code the cause looks like a single pinned locale:
amount.toLocaleString("en-US", { style: "currency", currency })
Passing the account's locale there instead would fix every currency at once. Worth using the account's country rather than the currency, since EUR is written four different ways across the countries that use it.
One warning for whoever tests the fix: Mexican number convention is identical to American, so MXN looks correct and shows nothing. German or Swedish shows it immediately.
Related, in case it is the same fix: with the platform language set to German, the invoice list inside the app still shows dates as "Sep 10, 2026", and the summary tiles read "3 Rechnung(en) im Entwurf".
P
Paul Foster
This is really annoying. How can you sell this product to the UK and only have american formats????????? Sort it out!
K
Keith Besherse
The American date format is stupid!
V
Victor Carcoba
+1 from an Australian business. We use DD/MM/YYYY across all client-facing documents (quotes, invoices, contracts) and the US format on our estimates and invoicing pages causes real confusion for our customers. Two requests under one umbrella that would solve this for the whole AU/UK/EU market:
- Add an "English (Australia)" option in Platform Language so localisation flows through the whole sub-account (currency is already AUD, timezone already AEST — only date format and language locale are missing).
- Honour the sub-account timezone when formatting dates, so estimates, invoices, conversations and SMS all render DD/MM/YYYY automatically when the location is set to a non-US timezone.
This is now sitting at 240+ votes and "under review" — would love an update on roadmap timing. Happy to beta test from the Gold Coast.
S
Steve Dawson
Definately needed
T
Trey Sobers
its now 2026 and nothing has been done about something so basic. insane
K
Keith Besherse
Trey Sobers, yes, it is basic and seems like an essential step for an international platform, yet, here we are...
T
Trey Sobers
Keith Besherse insane man. They need to focus on squashing these easy wins instead constantly rolling out grandiose features
K
Keith Besherse
Trey Sobers, I agree. But it is not the HighLevel way!
S
Sean Harrison
Sales & Marketing will this ever be updated?
I have clients in the travel space and when their customers are looking at a flight date which looks like the wrong date to them that's a huge issue
S
Sean Harrison
Worrying that this was so long ago and hasn't been edited at all since the suggestion. There are users all across the world and this is needed ASAP
All of my client's customers need to have clarity with the date in the right format for their region
K
Keith Besherse
YYYY-MM-DD HH:MM:SS please
Load More
→