Club Log applies the official rules of ARRL's DXCC award scheme exactly, using its extensive knowledgebase of exceptional callsigns and historical operations that either have or have not been accepted for DXCC to validate the QSOs in your log. Once you upload your log to Club Log, Club Log will check and then count the valid DXCCs you have worked and may have confirmed, and display the counts on its log reports and league tables. 

Hopefully Club Log's DXCC numbers are identical to the statistics reported by your logging software, but if there are discrepancies you can investigate and resolve them as follows:

The DXCC count is slightly wrong

If a small discrepancy is found, check the email that Club Log sent you after you uploaded your log. Did Club Log report any warnings or errors, perhaps rejecting some of the QSOs you claimed?  If so, the email report is a good clue about the reason for the discrepancy.


Various DXCC errors crop up repeatedly due to limitations of some logging programs (e.g. routinely identifying KH7 calls as Kure Island, whereas most are on Hawaii) and out-of-date country files. Most now incorporate Club Log as a source of definitions, so this is something to check (has your logger updated its definitions recently?).


To check further, use the Log inspector (in the left menus) to check Club Log's analysis against your logging software. Look up a DXCC country or callsign that you are sure you have worked but is not showing up in the reports. Does Club Log map it to the same DXCC country as your logging program? Double-check that the date of the QSO is within any stated range. Check the dates carefully, and also check the notes. 


Don't forget that QSOs with DXpeditions are usually only valid for the DXCC concerned within the specific dates and times of the operation: if you log QSOs outside of that strict range, Club Log (and the DXCC desk) will normally reject them. A common reason is that dates have been recorded or transcribed wrongly (typically the days and months have been swapped, or the QSOs were logged in local time instead of UTC).

If you expect to see a QSO confirmed, but it is only marked as worked, remember to check your ADIF. If that doesn't show a QSL_RCVD=Y or an LOTW_RCVD=Y, it will not be credited in Club Log. If Club Log says the QSO is "Invalid", check your ADIF closely (remember that the ADIF you upload is the only source of all the information you see).


At the end of the process, if you remain convinced that you are correct but Club Log is wrong about a given QSO, approach the Helpdesk with everything (including the ADIF record please). Try to only do this if you have exhausted other avenues and checked the points, above (thank you).


The DXCC count is completely wrong

If the DXCC counts in Club Log are significantly inaccurate, use the Log inspector or Call tester tools (both in the left menu of Club Log) to check a few calls for countries that you know you have worked but are not showing in Club Log. You will probably find they have been mapped to "Invalid". In extreme cases, you might find that all of your QSOs are invalid!

The most common reason for this is that the ADIF uploaded has claimed a DXCC value of 0 (zero), or a QSL_RCVD status of "I" (meaning invalid). These are both accepted ways to mark a QSO claim as invalid in ADIF files. Some logging software invalidates everything! Club Log doesn't report these as errors in your upload since this is the proper way to invalidate QSOs.

ADIF is a plain text file format so you can check and if necessary edit an ADIF file using an ordinary text editor such as Notepad.

Here's a typical ADIF record in a file downloaded from LoTW (line numbers and the green line have been added by the help desk software):  
<APP_LoTW_OWNCALL:4>ZM4G
<STATION_CALLSIGN:4>ZM4G
<CALL:6>SM7GIB
<BAND:3>20M
<MODE:2>CW
<APP_LoTW_MODEGROUP:2>CW
<QSO_DATE:8>20130922
<TIME_ON:6>065332
<QSL_RCVD:1>Y
<QSLRDATE:8>20140310
<DXCC:3>284
<COUNTRY:6>SWEDEN
<APP_LoTW_DXCC_ENTITY_STATUS:7>Current
<PFX:3>SM7
<APP_LoTW_2xQSL:1>Y
<eor>

The text between angle brackets is the field definition consisting of a field name (according to the ADIF standard), a colon separator, and the data length in characters. The text that follows is the data value for that field. Depending on how it was generated, your ADIF file may well contain different fields, or list them in a different order.


For example, if you are looking for a QSO with G7VJR which is missing or invalidated in Club Log, search the ADIF file for "<CALL:5>G7VJR" using the text editor's search function until you find the QSO record you're looking for. 

Does it have a DXCC value of zero, or a QSL status of "I" for Invalid?  Does it state that the DXCC country code field is 3 characters long, but in fact the data is just 2 digits?  Does it end with an <eor> or <EOR> end-of-record marker?

Once you have identified a problem in your ADIF, you could simply correct the error and re-upload the ADIF to Club Log ... but that will not solve the original problem. It is much better to correct your original log so that the next time you happen to do an ADIF log export and upload to Club Log, the error will not come back to haunt you.


If it's not immediately obvious how to correct the log in your logging software, check the embedded help or get support from the supplier of your logging program. All loggers allow users to edit callsigns, dates, modes, bands/frequencies, QSL and LoTW status etc. manually, or at least to delete and re-enter QSOs. Most also allow users to change the DXCC countries allocated to QSOs in the log, using either the numeric country code or the name of the DXCC entity.


Please don't ask the Helpdesk for help until you have checked your ADIF file with care! Thank you.