Location of NameSpace declarations in SOAP Messages

Question

I have written a WebService Client in Java (Spring) that produces the following SOAP Message

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header>
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" SOAP-ENV:mustUnderstand="1">
            <wsse:UsernameToken wsu:Id="UsernameToken-636BB26257F688077A14836055821331">
                <wsse:Username>
                    <!-- Removed-->
                </wsse:Username>
                <wsse:Password>
                    <!-- Removed-->
                </wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
        <To SOAP-ENV:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://fi422helswb035/invoicewstest/ProblematicInvoiceWebService.svc/externalpartnerInvoiceWebService</To>
        <Action SOAP-ENV:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://invoice.externalpartner.com/WebServices/IexternalpartnerInvoiceWebService/GetInvoices</Action>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <ns4:GetInvoices xmlns:ns2="http://schemas.datacontract.org/2004/07/externalpartner.Invoice.Web.Service.Interfaces.Types" xmlns:ns3="http://schemas.datacontract.org/2004/07/externalpartner.Invoice.Web.Service.Interfaces" xmlns:ns4="https://invoice.externalpartner.com/WebServices/" xmlns:ns5="http://schemas.microsoft.com/2003/10/Serialization/" xmlns:ns6="http://schemas.datacontract.org/2004/07/externalpartner.Invoice.Web.Service.Exceptions">
            <customerNumber xmlns="https://invoice.externalpartner.com/WebServices">10134</customerNumber>
        </ns4:GetInvoices>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

This message is Rejected on the server side with a 500 error. I can invoke the service with SOAP-UI; the following message (produced by SOAP UI is accepted)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="https://invoice.externalpartner.com/WebServices/">
<soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsse:UsernameToken wsu:Id="UsernameToken-134751B2732DA1D93F148360576695534">
            <wsse:Username>
                <!-- Removed-->
            </wsse:Username>
            <wsse:Password>
                <!-- Removed-->
            </wsse:Password>
            <wsse:Nonce>
                <!-- Removed-->
            </wsse:Nonce>
            <wsu:Created>2017-01-05T08:42:46.955Z</wsu:Created>
        </wsse:UsernameToken>
    </wsse:Security>
    <To soapenv:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://fi422helswb035/invoicewstest/ProblematicInvoiceWebService.svc/externalpartnerInvoiceWebService</To>
    <Action soapenv:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://invoice.externalpartner.com/WebServices/IexternalpartnerInvoiceWebService/GetInvoices</Action>
</soapenv:Header>
<soapenv:Body>
    <web:GetInvoices>
        <!-- Optional:-->
        <web:customerNumber>10134</web:customerNumber>
    </web:GetInvoices>
</soapenv:Body>
</soapenv:Envelope>

The real difference I can spot is the up front Name Space declaration in the accepted message. The web namespace is declared in the Envelope element - and in my rejected request it is declared in the element itself.

There are obviously also the missing a nonce and created elements, but according to the Oasis standards, those are not mandatory.

The question is; does the SOAP specification dictate where namespace declarations should be done? My best guess is that the rejected SOAP message is perfectly valid, and that there is a server side issue here...