UNF to 3NF is this relation workable?
You need to learn the difference between repetition and redundancy.  Sometimes a field value is repeated coincidentally.  This kind of repetition cannot be normalized out.

Normalization is about studying the functional dependencies between key and non-key elements.  It is not about putting everything that might occur twice into a table with a surrogate key.  

For example, you say that a phone number may be used by multiple companies and have modeled phone number as an independent table.  This would prevent update anomalies if when one company changed its number all of the other companies using that number changed theirs at the same time and in the same way.  Does any of that actually make business sense?  It doesn't to me.

Also, normalizing geography into a hierarchy is a questionable proposition.  However, you haven't even normalized into a hierarchy.  Is region ID not determined by country ID?  If so, your LOCATION table is not 3NF.  Similarly, are there postcodes that bridge states?  I don't know the Australian system well enough, but I know that in Canada, the US and the UK this doesn't happen.

You've designed everything like its a star schema and company is the fact.  Facts in star schemas are usually transactions, not static entities.  Transactions don't tend to change their properties, because they usually represent something that actually happened and one doesn't generally go back in time to change history.  Static entities live for a long time in your data (maybe forever) and change their properties fairly often.  Star schema is not a good, efficient model for this type of data.

What you should do is run queries on the frequency distributions of each column and on combinations of columns that you think may be keys combined with columns that you know aren't keys.  This will help you test your assumptions about which columns are truly able to act as keys.  Then you should temper those findings with some common sense around what could potentially happen to your data in terms of changes to column values.  Once you know your actual functional dependencies found in your data, then follow the relatively mechanical process of moving your relation to 3NF.