Some thoughts -
Any given loading system is designed by the WCO to suit the aircraft data. The system can be set up based on metric or imperial units (or any other units one might prefer - doesn't matter at all providing things are done consistently). The only problem using any system if the starting data is in different units to the system's design, is that the numbers will be incorrect and it won't work. Hence the need to convert to the system's units prior to entering the data.
On this point, there is one problem you all need to keep in mind for your flying if you are using trimsheets (along the lines of the Alpha system). It is very common for the trimsheet designer to use a datum position which is different to the manufacturer's.
The manufacturer of most light aircraft will choose a datum convenient for the design organisation, the design process, and general spares convenience. The loading system, usually designed by whichever of the aerodynamics group folks drew the short straw, follows from that datum.
The Industry WCOs, however, are not constrained by the OEM data and can choose whatever datum they may consider appropriate. Generally, for accuracy reasons with graphical systems, the best datum position is one which is somewhere in the aft half of the CG envelope. Most of us have our own little preferences - I tend to use the aft-most CG limit which gives a nice boxy envelope in the trimsheet.
The problem arises should another WCO issue data to be used with the trimsheet and, for whatever reason, didn't realise that the datum used was non-standard (ie not the same as that chosen by the OEM). In this case the data issued will be incompatible with the trimsheet.
For instance, years ago, a good friend (LAME and WCO) reissued the LDS for a cabin class light twin (for all the right reasons after some minor modifications) but didn't know enough about such systems to recognise that my design used a non-standard datum. The POH data he issued was totally incompatible with the existing trimsheet. One of the considerations I take, when designing trimsheets with a non-standard datum, is to endeavour to make the sheet's design incompatible with entry data based on the OEM datum so that, where the problem described above occurs, the pilot should be alerted to the problem because he/she can't get a sensible solution from the trimsheet. In the case cited, the CP for the operator, who was a mate of mine, caught up to me the next day (prior to a charter) with the complaint that the trimsheet didn't work. We fixed up his problem quickly (ie calculated the correct data) and he was able to head off for his charter. When I gingerly raised the subject with the LAME, the latter was horrified. An hour or so of briefing and he had a good understanding of the problem which was fine for any work he had to do in the future.
As a side note, pretty well all heavy aircraft OEMs provide for two datum positions to get around the accuracy problem The design datum is similar to what you see in light aircraft, while the second datum is chosen for loading system work only and, usually, is referred to as the "trim datum".
So, if you are flying an aircraft with a trimsheet loading system, you need to be able to recognise whether the entry data for the sheet are compatible with the sheet. It is probably worthwhile reading through the trimsheet thread on this site to get an idea of some of these concerns - see
bobtait.com.au/forum/rpl-ppl/5236-aircra...loading?limitstart=0
Some additional comments to Bob's post, for the Alpha, to amplify his observations.
When you enter the IU at the top of the page, you are doing exactly the same thing as when you fill in the first line entries for a conventional tabular load calculation. In particular, you are entering the empty/basic/(whatever term is appropriate) weight IU for the loading system. As you come down to each trimline, in turn,
(a) the distance you move (left/right) is the distance of the calculated IU (ie the IU change for the load at that load position) measured against the background IU grid (for which the scale is the IU entry line at the top of the sheet)
(b) the direction of the arrow (if to the right, you are adding the IU calculated for that load position, if the left, you are subtracting it) indicates the numerical effect on the progressive IU total exactly as you would do in a longhand calculation by adding/subtracting IU values for each load position.
(c) when you get down to the envelope, the final line which drops into the envelope is the total IU for the load arrangement, again, exactly the same as what you calculate in the manual add-up-the-values system
All the trimsheet does is make the calculation quicker and easier, while achieving functional accuracy similar to the longhand calculation. (This does presume that the trimsheet design is sensible - as you can see in the thread cited above, that sometimes isn't the case, unfortunately. Hopefully, CASA will address that issue at some stage as we still see the occasional dreadful attempt at trimsheet design, as can be seen in the other thread's examples of how not to do it).