Biztax export language


What would be the appropriate way to select the language for the .Biztax export?

We tried

  • Changing the display language of the application
  • Changing the language on the client level (what does this setting actually do? We don’t see it used anywhere, as the language of exports is also defined by the export style)

We’re looking to change this node in the .Biztax export:

    <pfs-vl:XCode_LanguageCode_NL contextRef="D0">NL</pfs-vl:XCode_LanguageCode_NL>

Is there any other setting we need to change?

Kind regards,


Hi @Wsteppe,

We only support biztax export in DocumentLanguage ‘NL’ for now.

What is the specific reason why you would prefer another language?

I’ll first check internally why only NL is supported and I’ll come back with some detailed feedback on this asap!

Kind regards,

The feedback that I get from our filing administrators is that the .Biztax value overwrites the value present in Biztax. This also applies for the address. So we’re basically setting all our clients to another language.

Apparently they can switch the language of the draft tax returns, but the language of both the final tax return and the language of the proof of filing are determined by the language code used in the .Biztax file. So our FR clients would get a NL final tax return + proof of filing.

Note that switching the ISO code of the language might not be sufficient, the following fields might also switch dependent on the language, and apparently do not switch in the current .Biztax export:

    <tax-inc:TaxReturnType contextRef="D0">VenB</tax-inc:TaxReturnType>

You probably want to replace this by “Isoc” or similar

      <pfs-gcd:DocumentIdentifier contextRef="D0">Aangifte</pfs-gcd:DocumentIdentifier>

This one you probably want to change, although I don’t think it’s required.

    <pfs-gcd:IdentifierName contextRef="D0">Ondernemingsnummer</pfs-gcd:IdentifierName>

This one you probably also want to switch to “numéro d’entreprise” or similar.

I think it would make sense if this behaviour would be triggered from the language setting on the client level

Hi @Wsteppe,

Thank you for this clear feedback!

As we are not that familiar with the practical side Biztax filing, the development team responsible will further investigate this.

Needs to be said, it’s the first time we received this feedback. So thank you for flagging this!

We’ll look into this and see what we can do, but any changes would probably only reflect as from next year’s filing as the filing deadline is coming up (November 16) and our focus will mainly lay on blocking issues for this filling deadline.

I’ll keep you updated on this.

Kind regards,

Hi @Wsteppe,

As promised, I’ve double checked this with the development team responsible for the biztax exports from Silverfin. This is the feedback I received.

The language setting as such in the .biztax file does not trigger a change in the language of the official tax return nor of the filing receipt. Biztax overrules the language information provided in the .biztax file. The file will not overwrite the Biztax settings.

The name of the document you download is in fact always called “Ontvangstbewijs” or “PDF_van_de_aangifte” due to the NL code. Nevertheless if you open the document it will still be in French.

Based on this feedback I believe there is nothing we can or should change on the DocumentLanguage in the .biztax file.

Do you agree on this?

Happy to hear your feedback!

Kind regards,

I’ve been browsing our filed tax returns, and I’ve found an example of a FR tax return with FR proof of filing. So unless Biztax has changed in the meantime it indeed appears to be only the title of the document. Thanks!

In the FR return, the filed values as marked above (ondernemingsnummer & VenB) are still in Dutch, so ideally they would be translated to French if required, and the document tag would be translated as well.

Obviously, if we’re able to draw a FR tax return and proof of filing from the platform, this is more a matter of putting the final dots on the “i” and the priority of this issue becomes a lot lower :slight_smile: