Count them once on your own table and you stop re-creating them. Every Dataverse table carries a fixed set of columns the maker never authored, and the count is not a guess: in Microsoft’s own CoE Starter Kit release, 46 tables carry 1,586 columns between them, 812 of which nobody created, and the same twelve appear on all 46 -

createdby, createdon, createdonbehalfby, modifiedby, modifiedon, modifiedonbehalfby, importsequencenumber, overriddencreatedon, statecode, statuscode, timezoneruleversionnumber, utcconversiontimezonecode

Tables that use owners or business process flows add more (ownerid, owninguser, owningteam, owningbusinessunit, processid, stageid, traversedpath) - admin_App carries 20 in total.

The one that surprises people is overriddencreatedon, because the mapping is the reverse of what the name suggests:

To import data in the createdon column, map the source column that contains this data to the overriddencreatedon column. During import, the record’s createdon column is updated with the value that was mapped to the overriddencreatedon column and the overriddencreatedon column is set to the date and time that the data was imported.

So after a migration, createdon holds the original date (the one you mapped) and overriddencreatedon holds the day you ran the import - not the other way round. Any report that reads overriddencreatedon as “when the record was really created” is reading the migration date. Map nothing and createdon becomes the import date and overriddencreatedon stays empty.

And importsequencenumber is how you audit one import. Each import job stores a unique sequence number in that column on every record it creates, so one number identifies exactly the rows a given import produced - which is the question you actually have when something goes wrong halfway.

Try it

Run the artifact against a solution you ship and get your own numbers in the first three lines.