Oops,
seems I misspoke:
https://vbaf1.com/variables/currency/
describes a currency datatype to use in calculations (also bigint with 4 decimals to output), but those numbers with more decimal places in your sheet are NOT curreny data type
update
As Bill writes, you might just import those as floats - or try a decimal format if you checked the data
BUT the following sill holds
/update

I was bribed for a number of years to move manmade Excel sheets playing database into real tables.
Had some classes for data cleaning - but it was almost never a process without some needed manual cleaning or override.

Typical way of doing things was to export as "CSV" and importing all columns into large text or memo fields.
That way no information still in sheet is lost - but some information like leading zeroes in phone or zip fields never made it due to not being preformated as text, making human validation / correction necessary.

If the information is valuable, set up an import process with a human clearing point.

been there, done that, destroyed keyboards...
thomas

>We do not have any control on the incoming data sources. A column, formatted for currency display, is sometimes containing data in the column such as 0.13077, 434, 123.34, 4.12121 and 134.99. We thus need to preserve the real value up to the database. Otherwise, total amount of that row (unit cost * quantity) in Excel would not be the same as what we would obtain from the database when showing the report in Power BI.
>
>We believe that this engine recognizes a currency formatted value from Excel and binds this to the money type of SQL Server. This would then be limited to 4 decimals.
>
>However, in our case, it would surely be nice to preserve the real values. For those exception files, we might look at an intermediate process to change the Excel cell format to Number before importing the data.
>
>Thanks for the reply, this is very useful.