If I understand correctly, you are presenting 2 CHILD tables below that have a parent INVOICE table. If this is correct, I have only 1 child table in my application with a field to indicate the type of *line item* this represents. When you have 2 child tables, you will find it more difficult to print invoices with line items from both child tables -- you have 1 parent table with 1-to-many relations into 2 different tables.

>I'm looking at how I might set-up some tables in a current project. I have invoices that can have either invoices "costed" against it, or Labor. This information is used to calculate the profit. Is there any benefit to having two different tables, one for Costed_Labor, one for Costed_Invoices, or just having one table that contains both?
>
>I'm thinking the general format of the tables would be:
>
>Costed_Invoices
>-----------------
>iid : Primary Key
>OurInvoice_FK : Foreign key pointing to invoice this is costed against
>PostingDate
>InvoiceDate
>InvoiceNum
>Amount
>Vendor_FK : Foreign key pointing to vendor for this invoice
>
>Costed_Labor
>-----------------
>iid : Primary Key
>OurInvoice_FK : FK point to our orig. invoice
>Worker_FK : FK pointing to worker info
>Hours : Hours worked on this invoice
>Amount: Amount paid per hour
>
>
>This could easily represented by only one table (by merging the fields). Any downfalls to either approach?
>
>-Paul