You have it backwards.
Create the tables, then the reports, THEN worry about the forms. You can denormalize the data for the forms via queries if necessary.
You have what's called a many-to-many relationship. You have multiple clients, multiple forms, and each client can have any number of these forms included. What I would do is set up a junction table - tblClientForms, perhaps. Layout would include the client's ID or PK field, the document's ID or PK field, and any tertiary data - perhaps 'IsNecessary', 'IsSubmitted', 'DateReceived', 'DateDue', who knows.
Perhaps when the client is set up, you can include a list of all 'necessary' documents, or you can skip that and just list whatever has been received.
Anyway, on the client's info form, I would have a button that opens a pop-up which lists all the available documents, along with 'Select' checkboxes and perhaps fields for any required dates.
Your user checks the boxes for each form, and then presses a command button which runs an append query that adds a record to the junction table for each selected form. If you included dates or any other data, this can be submitted at the same time. Once the update is done, close the pop-up and refresh the client form. Include a subform showing all documentation, and the refresh will update that to show the documents that were just selected.
This is a bit more complicated than just adding 50 Y/N columns to the client table, but it follows normalization rules and actually allows for much easier customization (such as addition of new forms) than hardcoding every single document.
It's going to be a bit of work, however. Consider it a learning experience.
Also, get other opinions. Someone else may come up with a better, easier-to-implement solution for you.
