Pull payment data from an Excel table and push it through to our CRM.
What is the problem & what have you tried?
When the List Table Rows module runs in Make the date column appears as a number e.g. 46176 where in my table it’s showing as 6/3/2026 (UK date format.)
I have tried using formatDate but this didn’t seem to work. I also tried parseDate but the output was incorrect (see screenshot) - the output was “1 January 1970 12:49”.
select the multiplicator from the menu instead, cause that star you have is just a text string. You may also need to parseNumber() around the incoming date, depending on its format.
Can you also show a screenshot of what the input looks like?
Thanks for the tip around the multiplicator, I have added this! The date output is now showing as “4 June 2096” which is different but still not right. See below input from the excel table and then what that looks like when it comes through the List Table Rows module:
Ok can you check the sheet if its American format? So the sheet is June 3rd, which means its 1 day off. So this could be a time zone issue. Check the time zone of the Make account and test with some different dates to confirm this. Then you can just add -1 days to it and it will match.
I cannot explain to you how much I hate Microslop’s products and strongly advise you to move away from Excel as soon as possible.
Apparently you need to subtract 25569 from the date before multiplying by 86400 to get the correct unix timestamp…Even then, I suggest testing with a couple of different dates to verify you are not getting the ±1 day issue.
If you’re using parseDate, you need to input the UK timezone (Europe/London) instead of X in the function.
Afterwards, you can put that inside a formatDate function like so: formatDate([the entire first formula]; DD/MM/YYYY)
I’m not certain you need the parseDate function, but give it a try.
Based on the above, you may have asked a duplicate question. Before creating a new topic in the forum, you can search this forum for existing answers and the Help Centre to get to a solution faster.
Still require assistance?
If the previous/related discussions are not similar to your question, please reply providing additional details to demonstrate the difference(s) between your question and the ones above.
If you require help understanding or implementing workarounds/solutions in the related discussions, please reply with more details of what you have tried, including screenshots.
I ran into a similar situation when working with Excel serial dates in automation tools. At first it’s confusing because Excel stores dates as numeric values, so when they move into another system the format doesn’t always translate properly. Using parseDate with the correct timezone and then wrapping it with formatDate is actually a clever way to handle it.
Timezone differences are something many people overlook, so specifying Europe/London in the function is a really helpful tip. Once the date is parsed correctly, formatting it into DD/MM/YYYY becomes much easier.
When I deal with spreadsheets and time-based data, I sometimes double-check values with small utilities or simple date calculation tools before applying the final formula in a workflow. It helps avoid mistakes when the numbers look unusual at first.
What is your goal?
What is the problem & what have you tried?
Screenshots (scenario flow, module settings, errors)
