I think the best way to approach this would be to have tables like so:
table Customer
ID
Name
...
table CustomerFields
CustomerID
FieldID
FieldName
... (could have things like type, required/optional, size, etc.)
table CustomerOrders
CustomerID
OrderID
OrderNumber
DeliveryDate
... (all your generics and mappable fields)
table CustomerOrderFields
CustomerID
OrderID
FieldID
FieldValue
By having the table CustomerOrders, you satisfy the ability to map common customer order data to common fields (simplifying reporting at the expense of making the import a little more painful since the fields must be mapped), and the CustomerOrderFields gives you the ability to have the custom fields per customer necessary for the un-mappable data.
The custom fields are still reportable, but not as easily as your generics as they'll come to you in multiple rows (instead of multiple columns). There are some ways around all that depending on your report creator (e.g., pivoting the results).
The only other option would be to do something like this (which, personally, I would avoid):
table CustomerFields
CustomerID
Field1Name
Field2Name
Field3Name
...
Field99Name
Table CustomerOrders
(all your generics)
Field1Value
Field2Value
...
Field99Value
This has the advantage that all your data is in one row, but also has the disadvantage that it isn't immediately apparent from the row what each value means. The first method can always be joined to the field list to give a good definition of the data in each custom field. In addition, what happens if some company requires 100 custom fields? In the above example, you'd be making changes to your data structures and code whereas in the first example, you'd never have the issue -- customers could have infinite custom fields.
I've seen it done both ways, and both ways work. Both ways have their downsides and upsides. The first is far more scalable, but harder to get in to columns (instead of rows). Everything's a trade-off.
Hope that helps some!
Pros - It is the natural key, it makes sense and it will likely be searched on, I presume?
Cons - The default behavior (which is totally changeable) is for a primary key to be the clustered index. An alphanumeric doesn't make the best candidate because inserts can cause page splits because they aren't set on an ever increasing value like an identity column. The Int identity column will take less space (4bytes) compared to the character data (40+bytes for the unicode) . This makes your other indexes larger since the clustered key is part of them. If you ever change how you identify your customers and make customer codes, this all breaks - going with a surrogate insulates you from those type of changes.
In this situation, I tend to optimize for the insert performance and go with an identity column more often than not for the clustered key and primary key. I really like integer clustered indexes. (Now I know your question was not about clustered index, it was about primary key... You could still choose some other column to be the clustered index and make this your primary key, you could also put a unique constraint on this and treat it as a natural key but not make it your primary key).
I would at the very least index this with a unique constraint and treat it like a natural key. I just don't know if you really need to make it your primary key.
Kimberly Tripp is a trusted resource who has a lot to say about primary keys and (more so) clustered keys on her blog - https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/
This is all just my opinion - YMMV.
Best Answer
Some good criteria for choosing or designing keys are: Simplicity, Stability and Familiarity but first you need to understand the fundamental business requirement your key is supposed to address. Ask yourself how you intend to identify customers in your business processes. Assuming you have a requirement to identify customers and Customer Number is the means your business will use to do that then it makes perfect sense as a key in your customer table - not necessarily the only key, but certainly a key of that table.