You can compile a high-level language down to a byte code which looks like machine code but which does not correspond to any actual hardware. Instead, the byte code is interpreted. Python and Java both work this way.
You can also compile a high level language down to machine code that runs on actual hardware, like an x86 or an ARM. For languages that run on more than on processor, the compilation process usually consists of an architecture-independent phase which produces some sort of intermediate representation (which may be a byte code, or it might be something else, like LLVM) and then an architecture-specific pass that transforms the intermediate representation into machine code for the target architecture. The code that implements that second pass is called the "back end."
I have no idea whether Erlang compiles to native code or byte code.
In addition to all that, there can also be a run-time environment that is required to run the resulting code. For byte code, this environment necessarily includes an interpreter for the byte code, and might also include other things. For native code this environment might include things like a garbage collector or a standard library that provides an interface to an operating system or something like that.
There are multiple passes, the last of which is byte code although at one point, native code was (is?) an option with HiPE (High Performance Erlang). HiPE seems to have been passed over by the development team in favour of JIT.
The lines begin to blur in fun ways with JITs, I think, too. I believe Erlang with BeamAsm does bytecode compilation for the BEAM VM, which JITs it to native code (via AsmJit, a neat C++ library it seems?)
You can also compile a high level language down to machine code that runs on actual hardware, like an x86 or an ARM. For languages that run on more than on processor, the compilation process usually consists of an architecture-independent phase which produces some sort of intermediate representation (which may be a byte code, or it might be something else, like LLVM) and then an architecture-specific pass that transforms the intermediate representation into machine code for the target architecture. The code that implements that second pass is called the "back end."
I have no idea whether Erlang compiles to native code or byte code.
In addition to all that, there can also be a run-time environment that is required to run the resulting code. For byte code, this environment necessarily includes an interpreter for the byte code, and might also include other things. For native code this environment might include things like a garbage collector or a standard library that provides an interface to an operating system or something like that.