The closing sequence can also be different and don't need to have FIN+ACK inside the same packet:

• ACK just acknowledges the receipt of data (e.g. received everything up to given sequence number)
• packets will be re-send until one receives an ACK for them
• FIN just says that the side sending the FIN will not send any more data. It gives no information if it will still receive data.
• like every other packet FIN will be re-send until the receipt is acknowledged

Protocols like HTTP support a one-sided shutdown, e.g. the client sends the request data followed by a FIN to notify the server, that it will not send anymore data. But it will still receive the data send by the server. The server will acknowledge the FIN like it did with all the data before. Once the server is done it will send its own FIN which the client ACKs. In this case you have

1. client: FIN  (will not send more) 
2. server: ACK (received the FIN)
.. server: sends more data..., client ACKs these data 
3. server: FIN (will not send more)
4. client: ACK (received the FIN)

Note that the packet you see in step#1 might have an ACK inside too. But this ACK just acknowledges data send before by the server. If the server has no more data to send it might close the connection also. In this case steps 2+3 can be merged, e.g. the server sends a FIN+ACK, where the ACK acknowledges the FIN received by the client.

If one side sends its FIN the connection is called half-closed. It is fully closed once both sides send their FIN and received the ACK for the FIN, no matter if they do this in 3 or 4 packets.

You must have already received the FIN for you to be sending a FIN/ACK. Are you closing in response to reading EOS?