<p>I have a system that creates an order and that order can be billed to a house account, sent Cash on Delivery (COD), or charged to a credit card.  I've created the following tables:</p>

<p>ORDERS<br/>
order_id<br/>
billingoption_id</p>

<p>BILLINGOPTIONS<br/>
billingoption_id<br/></p>

<p>I'm unsure of how the next table should be built for the billing data.  Should I build a separate table for each type of billing option (ie. COD, Credit Cards, and House Account)?  Then would I have another foreign key column on the Orders table that would refer to a record for the billing data?</p>

Focus on things.  Actual things.  Try to describe things simply, directly, and in natural language first.
Then, when you ask for design guidance, you can provide definitions.  In some cases, the act of writing definitions will make the design crystalize.
Orders
are things.  What are the attributes of an order?  Customer, Product, Payment/Billing options.
Billing Options
are (almost) things.  You can, apparently, define and identify them.  (I'm not sure I could.  From your question, it appears that you might be able to.  But without a one-sentence summary, I'm not sure what's going on with Billion Options.
What's a "billing data?"  What kind of thing is this?  What attributes (or properties) does it have?
How does a "Billing Data" relate to an Order?  How does it relate to a Billing Option?
Feel free to update the question with definitions for each thing.