Support #1541

Benefit income in indresp and income file: what accounts for the differences between frmnthimp_dv and fimnsben_dv, and how can I retrieve benefit amounts for non-matching records?

Added by Gabriele Mari over 2 years ago. Updated about 2 years ago.

Start date:
% Done:




I am using Understanding Society Waves 1 to 10. I am interested in income from state benefits. Using the income file and this Stata code:

drop if ficode==2|ficode==3|ficode==4|ficode==17|ficode>=24 & ficode<=29|ficode==35|ficode==38

collapse (sum) frmnthimp_dv if frjtkeep_dv==1, by(pidp wave)

I can reproduce the variable fimnsben_dv in indresp. The sum of frmnthimp_dv is equal to fimnsben_dv in indresp, at least for the person-wave observations that are present in both datasets. Yet, many observations in indresp have no match in the income file. For the vast majority of them fimnsben_dv is set to 0, but for 10,412 fimnsben_dv has a positive value but no corresponding record for that person from the income file. I was wondering how these positive values were computed. Specifically, how can I recover the income receipt for each benefit that was then used to compute fimnsben_dv for these person-wave records? I suspect these values are imputed from household members that declare joint receipt, but so far I’ve been unable to reproduce the numbers.

Also, am I correct in assuming that benefit amounts when receipt is joint are always divided by 2, in both the income file and in indresp?

Thanks in advance!


Updated by Understanding Society User Support Team over 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
  • Private changed from Yes to No

Many thanks for your enquiry. The Understanding Society team is looking into it and we will get back to you as soon as we can.

We aim to respond to simple queries within 48 hours and more complex issues within 7 working days. While we will aim to keep to this response times due to the current coronavirus (COVID-19) related situation it may take us longer to respond.

Best wishes,
Understanding Society User Support Team


Updated by Understanding Society User Support Team over 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 10 to 80


Our income team have suggested that the 10,412 cases should be proxy interviews. They do not appear on the income file as they didn’t do an interview and so were not asked the benefit questions. The positive fimnsben_dv amount for those cases are imputed amounts. There is no way to recover the individual benefit amounts for proxies.

On the joint receipt procedures, you can see section 7.2 here:

Hope this helps.

Best wishes,
Understanding Society User Support Team


Updated by Gabriele Mari over 2 years ago


thanks, that checks out and is really helpful. I have a follow-up, if I may. After excluding the proxy interviews, which variable is best to ascertain benefit receipt? I am focusing on legacy benefits and on Child Benefit. At the moment, I am torn between two alternatives. For Child Benefit, for example, I can create a dummy for whether income from Child Benefit is greater than 0 in the income file record. Or I can feed back one wave the corresponding ff_bentype variable, in this case ff_bentype18. As in:

ge cbfit=f.ff_bentype18

I find discrepancies between the two methods: almost all the discrepancies are coded 1 using f.ff_bentype, and 0 using info from the income file (they thus report an income of 0 in the income file). Most of the discrepancies are for benefits more typically received jointly, Child Benefit, Tax Credits and Housing Benefit.

Would you rely on ff_bentype or on the income file? Or combine them in some way?

Thanks again.

Best wishes,


Updated by Understanding Society User Support Team over 2 years ago

You should rely on the income.dta file. So if a respondent reported the source it will be listed there.


Updated by Understanding Society User Support Team over 2 years ago

  • Assignee deleted (Alita Nandi)

Updated by Understanding Society User Support Team about 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 80 to 100

Also available in: Atom PDF