Yes, you are right in your understanding about how private  works. However,
don't be afraid of "public". It's fine.

Try to treat your modules a bit like you'd treat classes or objects in
object-oriented programming. In other words, try to encapsulate a single
subject in a module with all the variables that hold its state (private),
all the routines that allow other modules to get it to do things (public)
and any needed "helper" subs and functions  (private).

Smaller projects don't need to be broken up like this, but larger projects
definitely benefit.

But anyway ... don't worry about having cross-module calls. They're fine,
and often are easier to understand than a single large module with lots of
fairly unrelated subs in it.

Do, however, get into the habit of using "dot" notation when referring to a
routine in a different module. E.g. "Call BankAccounts.Withdraw (xxx)", so
that (1) you know exactly where the sub is, and (2) your subs and functions
can have simple "action" names.

I also recommend that you get into the habit of using the "Call" keyword on
calls to subs, rather than just putting the name of the sub; and also that
you always enclose parameter lists in parentheses for calls to subs, like
you have to do for calls to functions. Neither is required by the compiler,
but IMHO they make the code more readable (especially the parentheses round
the parameters).