I would do a quick demo application to show them what you mean.  I did
that at work and FINALLY after like 4 months, they let me write a
properly normalized database with a front end (imagine taking 4 months
to decide that was okay!)  After that my life was MUCH easier.

I am with pietlinden on this.  This chance that you will ever get a clean
import is minimal.  Excel is really the wrong tool for this sort of thing.

Some things  you can take to the decision makers.
1.  It will be less expensive for them to use Access for data entry than
Excel.
There are extra operations required and there is the iterative process of
getting the data right.  Using Access, the user will not be allowed to enter
incorrect or incomplete data.  The productive time loss using Excel will be
significant.  Even if the entry is correct, importing sometime gets field
types wrong and the data has to be hand manipulated to get it to import
correctly.  Using Excel's flat file contruction, there is no way to ensure
any referential integrity.  All these issues add up to lost productivity and
thus money.

2. Data in Excel spreadsheets is totally unsecure.  Sure, you can put a
password on an Excel workbook, but then you have to remove it to be able to
import the data into Access.

3.  If the decision makers are concerned about the cost of deploying Access
to all users, that is not necessary.  A one time purchace of the Developer's
Tools is all that is required unless you are using 2007, then the are free.  
This allows you to deploy a runtime version of Access to the users so they
can use the application.  This is actually a good thing.  You can deliver an
mde or accde file to the users and they will not be able to make any
modifications to the applications or make any changes to the data without
going through your user interface.  It is an added security layer.

So take your lance and your talking points and go tilt with the windmills.