In CiviCRM you have a location type named billing. In addition to that, there is a checkbox named "Billing location for this contact".

As far as i know, CiviCRM will use the address that has the checkbox ticked whenever you do things that require a billing address such as creating an invoice - the location type is not relevant (correct me if I am wrong).

Having two options to mark an address as the billing address is extremely confusing for users. The location type cannot be disabled either and renaming the label is obviously not a good idea either.

Can anyone tell me why billing addresses are handled this way? Is there actually a chance to change that in a future release and if yes what would be the requirements to do so?

2 Answers 2


The location type is mainly as a "safe" way for recording a billing address that may differ from a contact's home, work, or other addresses. If you make a transaction that records a contact's billing address, you can't reasonably assume that the address is the contact's primary address. (Maybe it's your home address, or maybe it's the billing department of your employer.) In fact, there may be a primary address separately recorded on the contribution or event form.

Either way, you need to create an address, not overwrite an existing address, and not imply that it's a home, work, or other type of address. Consequently, contribution forms will use the "billing" location type and mark that as used for billing.

(The checkbox is relatively new, too, so there didn't use to be this ambiguity. However, the checkbox allows you to identify an actual location as the billing address so you don't have duplicate information.)

In practice, it's important to let your users know to use the checkbox, not the location type, for determining whether an address is for billing.

For future versions, I'd suggest that the billing location type wouldn't be necessary if contacts were allowed to have multiple instances of the same location type. For backwards compatibility, old sites could keep the billing location type, but new sites could just have a new home (or whatever default) address get added and marked as billing.

  • I agree that one definitely needs to have a clearly marked billing address - which is exactly why the combination of the checkbox and the location type does not make sense. Speaking of which - the checkbox has been around for years (at least CiviCRM 3.4 maybe longer). Hence I strongly support the idea of changing that in future versions and only have a checkbox (or a location type - I actually don't care). I will create a feature request on Jira and post the link here.
    – Fabian
    Commented Jan 7, 2016 at 9:19
  • By the way there currently is a bug: If you have an address of another location type than "billing" marked as the billing address (by the checkbox) and then use a form that creates a billing address it will update/create the address of the location type billing and mark its checkbox. However the checkbox of the other address will not be removed resulting in two addresses marked as billing addresses. Will report a bug for it too, and paste the link here. I would still welcome more feedback/views of other users on the whole topic.
    – Fabian
    Commented Jan 7, 2016 at 9:22
  • Here is the link to the bug report: issues.civicrm.org/jira/browse/CRM-17783 and the one for the improvement request: issues.civicrm.org/jira/browse/CRM-17784
    – Fabian
    Commented Jan 7, 2016 at 11:11
  • 1
    Thanks for reporting it--that bug really defeats the purpose of the checkbox. Anyway, by "relatively new", I just mean I remember a time before it existed.
    – Andie Hunt
    Commented Jan 7, 2016 at 12:14

We've picked this up at the code sprint in Edale, if you're interested please follow up here: https://issues.civicrm.org/jira/browse/CRM-17783?focusedCommentId=95284

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.