If a converter is specified on the <id> element in the compass mapping file, it is not honored (i.e. it doesn't work). However, if the annotation @SearchableId is used instead, the converter is accepted. The problem is identified below. In the MappingProcessorUtils, the method addInternalId uses the following logic (around line 100): internalIdMapping.setConverter(classPropertyMapping.getManagedIdConverter()); internalIdMapping.setConverterName(classPropertyMapping.getManagedIdConverterName()); at this point, the classPropertyMapping DOES have a reference to the converter specified in the mapping, but it is not passing it on to the internalIdMapping object. Rather, it is referencing the managedIdConverter, which is null at this point. The annotation processor is much more thorough, and it correctly binds both the converter and managedId converter to the converted specified in the @SearchableId annotation. This can be found around line 482 in AnnotationsMappingBinding. I discovered this problem because I use the generic java.io.Serializable interface for my artificial ids, and therefore a converter is required to extract the underlying value. For now I am going to stick to using annotations, but I figured the support should be the same for both methods. A unit test could easily guarantee that this bug isn't reintroduced.