For the attribute table, I meant something similar to the sys_prefs table in FA, but linked to each of the main entities in the payroll. If you have a pay items table similar in purpose to the FA items table, the pay item table itself would not have any columns specific to any one country but have a table linked to it to contain all the values of what would be country specific columns in the pay item table. I don't think you'd include the type and length of each attribute in the attribute table, unlike the FA sys_prefs table, but should probably have a separate attributes index table that defined all the possible attributes, their types and lengths and scope.
The payroll pay item attribute table would then just have the pay item id, the attribute index id, and the value specific to this pay item.
For example, the pay item table would have a code, description, a link to an FA expense account and fields to declare how the pay item is to be calculated. A pay item record for a salary would have a calculation method field that linked the pay item to the salary calculation function, and a separate tax pay item would link the item to the tax calculation function. But there are other attributes linked to a pay item that would have to be associated with specific countries, such as a tax category to indicate how that pay item is to be reported for tax, or perhaps how that pay item might be included in the total from which another pay item is calculated. Those types of attributes should not be columns within the pay item table, but perhaps each value stored as a separate record in a 'pay item attributes' table, linked to the pay item.
It then becomes possible to easily add processing for new countries whilst not upsetting the processing for countries already defined. You'd need attributes tables linked to each of the main entities in the payroll: the company, employees, pay items and payslip (pay check) records.
Adding a new country to the framework then means simply adding the new attributes, calculation functions and country specific reports. Hopefully the core tables would not need changing, but you might need to add country specific reference tables: the UK needs tiered National Insurance rate tables as well as tiered tax tables, and different countries quite often have different fields for each tax tier. For Australia there are two percentage rates involved in the tax calculation. For UK, you have to flag which tier is the basic rate tax, and so on.
I think you do need a separate table for payslips and payslip items, just as FA has sales order and sales order details, and the GL entries are generated from them. The payslip and payslip items tables also need their own attribute tables as some countries require values to be carried forward from pay to pay.
I have followed this design for a PC payroll system that is sold in Australia, New Zealand, United Kingdom, and several Pacific islands. It's worked quite well so far and it's relatively easy for me to extend the software for new countries. I had considered adding a payroll module to FA myself based on the same design, but I am a bit tied up with support and enhancements for that other payroll and don't have much time left.