Use UUIDs, that way you can account for having parent records coming in from two different sources.
If you need, you can pull the ID over from the ODBC data and use it as a temporary relationship to look up the new UUID from the parent table, or just use a simple replace calc on the billing table to match to the ODBC key from parents:
ExecuteSQL("SELECT primaryKeyUUID FROM parentTable WHERE oldSQLkey = ?" ; "" ; "" ; billingTable::oldSQLParentKey )
I'm with Mike. A 'temporary relationship' using key from the original source is often the only way.
Rather than use ExecuteSQL can I use the same statement in the SQL of the Import Records script?
No, because your UUID doesn't exist until after the parent record is in filemaker. You can populate it via a temporary relationship that only is evaluated during import, or without a relationship, using an ExecuteSQL() function as I wrote as part of a replace field contents script step.