SFTP integration using SFTP Uploader app

It is possible to upload invoices to an SFTP server and have them picked up from there automatically. It provides secure file system upload over a secure channel. Tradeshift provides a free account to a server where you can upload your invoices in a variety of formats.

See currently supported formats on our integration page.

So what is SFTP? SFTP stands for ‘SSH File Transfer Protocol’, it is not related to FTP except that it also transfers files and has a similar command set for users. If you are not familiar with SFTP it is recommended to find out more about it before continuing reading this page. There is plenty of information about SFTP available on the web.

In order to use this integration method you have to have an accounting or ERP software which is able to send documents over SFTP or an SFTP client (there are plenty of free SFTP clients available). You have also to activate the ‘SFTP Uploader‘ app from the Tradeshift apps.

To integrate your ERP, accounting system or SFTP client with Tradeshift, please, follow the following steps:

  1. Go to the SFTP Uploader app
  2. Generate OpenSSH RSA or DSA public and private keys. (see below)
  3. Paste generated public key into the text area
  4. Press ‘Save’ button to save the key and create an account at the SFTP server. If the key is invalid or in a wrong format an error message will show up.
  5. Copy the SFTP hostname, port and username shown below the text area
  6. Use SFTP hostname, port, username and your private key to configure your ERP, accounting software or SFTP client to connect to the SFTP server. SFTP server doesn’t need password.
  7. That’s it! You are ready to send invoices from your system or SFTP client to the SFTP server. Try to connect and put a document into the ‘outbox’ directory of the server.

Tradeshift’s SFTP server directory structure

Dir nameDescription
outbox
Directory used to put files to be processed by Tradeshift. Read more about supported document formats. Uploaded files MUST have unique names.
NOTE: This server implements different semaphore mechanisms to allow you to signal that an upload is completed. You MUST employ one of these methods – if you do not, the server will wait indefinitely for the upload to complete.
First semaphore mechanism: Using .ok notation
After succesfully uploading a file <filename> (e.g. invoice-1.xml), either: Upload a second possibly empty file named <filename>.ok (e.g. invoice-1.xml.ok), or: Rename from <filename> to <filename>.ok
Second semaphore mechanism: Using .tmp notation
Upload the file as <filename>.tmp (e.g. invoice-1.xml.tmp), and after successfull completion, rename the file to <filename> (e.g. invoice-1.xml).
Third semaphore mechanism: Using .filename notation
Upload the file as .<filename> (e.g. .invoice.xml), and after successfull completion, rename the file to <filename> (e.g. invoice-1.xml).Only one document (e.g. invoice, credit note) per one file is supported.
This server supports attachments to documents. Attachments are files which are attached to the target document. Attachments can be send only together with the original document. It is not possible to add attachments to already uploaded document.
Attachments file names MUST be unique for the target document.
If sending a document with attachments they MUST be uploaded to the server BEFORE the signal about completed upload of the target document (read about semaphore semantics above). Only ONE signal about completed upload should be made: the signal about the target document upload. Do NOT signal completion of attachment files upload.
If there are no attachments to the target document or they do not confirm to the document attachments naming convention, the target document is send without attachments.
The attachment file names to the target document MUST confirm to ONE of the following rules:
attachment[documentfilename]attachmentfilename
Name starts with the word ‘attachment’ and the file name of the target document inside the square brackets and followed by the file name of the attachment itself.
E.g. the attachment which original name is receipt.pdf and has to be attached to invoice which file name is invoice-01.xml must be put to the server with file name attachment[invoice-01.xml]receipt.pdf
attachmentfilename.attachment.documentfilename
Name starts with original attachment’s file name followed by ‘.attachment.’ and ends with the file name of the target document.
E.g. the attachment which original name is receipt.pdf and has to be attached to invoice which file name is invoice-01.xml must be put to the server with file name receipt.pdf.attachment.invoice-01.xml
Attachments are attached to the target document with their original file names (e.g. receipt.pdf). Attachments are REMOVED from the server after the document is processed, no matter successfully or not.
sentStores successfully dispatched files. Besides, there will be dispatch results file available for each sent document. The dispatch results file has the same name as the original file, but has ‘.dispatch.xml’ appended. More dispatch result formats can be enabled in the ‘Advanced’ tab of the SFTP.
failedStores files which didn’t pass the validation. Besides, there will be validation results file available for each failed validation file. It has the same name as the original file but ‘.failed.xml’ appended.
dispatchfailedStores files which pass the validation, but couldn’t be dispatched. Besides, there will be dispatch results file available for each failed validation file. It has the same name as the original file but ‘.dispatchfailed.xml’ appended. Dispatch might fail because of invalid e-mail address in the document.
dynamicvalidationsOptional directory. You have to activate Dynamic Validations app to have it enabled. It stores definitions of dynamic validation. The dynamic validation definitions are XML files defining fields of documents which should be validated against list of possible values that are dynamically uploaded to the dynamicvalidationchanges directory. The validations may define the sender and the receiver of the document for which the field must be validated. It is particularly valuable for an enterprise which has branches (see Branch Management) app: the different validations can be be defined for each branch by setting the branch as the receiver.All files must have the following mandatory fields:
Id – the unique ID of the validation definition
ReceiverId – the receiver of the document for which the validation must apply. It is defined by the scheme (for example “GB:VAT”, “DK:CVR”) and the actual value this scheme represents
Field – the XPath expression unambiguously defining the field of the document to apply validation to
DocumentType – the type of the document which is to be validated. For example: invoice, quote, etc.
Optionally, the SenderId could be defined. In this case the validation is applied only to documents sent by this particular sender.
NOTE: the file name must exactly match to the Id of the validation definition appended by “.xml” string.
Only one validation definition per file is allowed.
Following the SFTP’s server “.ok file” strategy, the file will be uploaded only after an empty file with the same name appended with “.ok” is uploaded to the directory.
networkOptional directory. You have to activate Van access app to have it enabled. The directory is used by the external value added networks (VAN) to send documents on behalf of their customers. VAN’s customers don’t have to be registered in Tradeshift. Tradeshift issues a unique ID to each VAN. Contact Tradeshift to request the ID.The VAN ID will appear as a sub-directory of the “/network” directory. This sub-directory works as the “/outbox” directory for the regular users, i.e. documents put into this sub-directory are dispatched. For example, a VAN witch ID is “van01” will have it’s outbox directory in the following location:/network/van01 NOTE: you can’t put files into the “/network” directory.
All rules and semaphore mechanisms of the “outbox” directory apply to this directory. Results are put in the regular failed, dispatchfailed and sent folders.

Dispatch Results

After the signaling that the upload is complete using one of the semaphore mechanisms, the file is converted, validated, digitally signed (optional) and dispatched to the recipient. All this is done asynchronously and take some time. Usually, it takes less than 1 minute, but in case when digital signing is involved or there is a heavy load of the server the dispatching may take more time. So, give the system 5-10 minutes before escalating dispatching issue to a problem. When the file has been dispatched successfully it is moved to the ‘/sent’ directory. Together with this file there will be a dispatch log file in XML format which has the same name as the original file followed by ‘.dispatch.xml’. This is the default Tradeshift dispatch result format. More result formats can be enabled in the ‘Advanced’ tab of the SFTP/FTP/FTPS app. Currently we support only ‘CONTRL’ which is EDIFACT format control message, but more formats will follow. If the dispatch has failed for some reason, the file is moved to the ‘/dispatchfailed’ directory. The dispatch result files can be found in this directory too.