> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tangoanalytics.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Invoice outbound file

# Tango Project Invoice Outbound — File

> Generated from `Tango Project Invoice Outbound Integration Design Specification V0.7.docx` in SharePoint folder `04 Projects Integrations`.
> OAS spec: [`invoice-outbound-file.yaml`](./invoice-outbound-file.yaml)

## Overview

SFTP file-based outbound integration. Tango writes approved invoices as a pipe-delimited text file with both header and detail information. The client reads the file from the SFTP server and loads it into its target system. After export, Tango marks the invoices as `Exported`.

**Owner:** Tango Analytics
**Spec version:** 0.7
**Status:** Draft (auto-generated from design doc — needs review)

## Transport

| Attribute | Value | |
| - | - | - |
| Direction | Outbound (Tango → Client) | |
| Mechanism | SFTP file drop | |
| File format | Pipe-delimited (\` | `) text, `.txt\` extension |
| File naming | `{ClientName}_Invoice_Out_MMDDYYYYHHMMSS.txt` | |
| Production host | `sftp.tangoanalytics.com` | |
| Test host | `sftpdev.tangoanalytics.com` (SIT/UAT) | |
| Path | `/outbound/invoice` | |
| Auth | SFTP user/password (credentials not in source) | |
| Frequency | TBD | |

Existing files are moved to `Processed/` with a timestamp suffix before each new write.

## Integration logic

* Tango pulls newly **approved** invoices and generates the file.
* If no approved invoices exist, no file is generated.
* Lines with `Net Amount = 0` are excluded.
* `INVOICE_ID` is the reconciliation key — the client must round-trip it via Invoice Inbound to mark a payment.
* `INVOICE_DETAIL_ID` uniquely identifies each line.
* Validations on mandatory fields are run before the file is written; failures land in the service log and are emailed to a client distribution list.

## Data fields

| Field | Type | Required | Sample | Description |
| - | - | - | - | - |
| `INVOICE_ID` | NUMBER | ✅ | `9879898` | Tango unique invoice ID |
| `INVOICE_NUMBER` | VARCHAR | ✅ | `09-32432` | Client-defined |
| `PROJECT_NUMBER` | NUMBER | ✅ | `43-42342` | Client-defined |
| `PO_NUMBER` | VARCHAR | ✅ | `42342-001` | Tango generates (Maintenance) or client-entered (Construction Projects) |
| `INVOICE_DETAIL_ID` | NUMBER | ✅ | `3412343` | Tango unique line ID |
| `LINE_ITEM_SEQ` | NUMBER | ✅ | `20` | Budget line sequence |
| `LINE_ITEM_NAME` | VARCHAR | ✅ | `Chairs` | |
| `INV_DATE` | DATE | ✅ | `1/21/2021` | `MM/DD/YYYY` |
| `TOTAL_INVOICE_AMOUNT` | NUMBER | ✅ | `5500.00` | |
| `TAX_AMOUNT` | NUMBER | – | `500.00` | 2-decimal rounded |
| `INVOICE_AMOUNT` | NUMBER | – | `5500.00` | 2-decimal rounded |
| `CURRENCY` | VARCHAR | – | `USD` | ISO 4217 3-char |
| `LOCATION_NUMBER` | VARCHAR | – | `23900-34` | |
| `SUPPLIER_NUMBER` | VARCHAR | ✅ | `26845-001` | Client-defined |
| `SUPPLIER_SITE_NUMBER` | VARCHAR | – | `26845-002` | Client-defined |
| `INVOICE_TYPE` | VARCHAR | ✅ | `REGULAR` | `REGULAR` / `RETAINAGE` |
| `PAYMENT_TERMS` | VARCHAR | – | `NET 60` | |
| `SEGMENT1` – `SEGMENT6` | VARCHAR | – | | Budget segments |
| `H_COMMENTS` | VARCHAR | – | | Header comments |
| `D_COMMENTS` | VARCHAR | – | | Detail comments |
| `STATE` | VARCHAR | – | | |
| `ZIP` | VARCHAR | – | | |

## Validations

| Condition | Error message |
| - | - |
| `SUPPLIER_NUMBER` null | `SUPPLIER_NUBMER not present on the invoice` *(spelling per source)* |
| `INVOICE_DATE` null | `INVOICE_DATE is not present on the invoice` |
| `INV_AMOUNT` is zero | `INV_AMOUNT is zero` |
| `INVOICE_NUMBER` null | `INVOICE_NUMBER is null` |

## Open Questions / Assumptions

* [ ] **SFTP credentials are blank in the source** — User and Password fields are left empty in the doc.
* [ ] **Timing/frequency is `<TBD>`**.
* [ ] **`PROJECT_NUMBER`** is typed `NUMBER` but the sample value `43-42342` contains a hyphen — likely a documentation mismatch; schema follows the table.
* [ ] **`INVOICE_DATE` vs `INV_DATE`**: the validation table uses `INVOICE_DATE`, but the data-mapping uses `INV_DATE`. Treated as the same field.
* [ ] **`INV_AMOUNT` vs `INVOICE_AMOUNT`**: similar drift — validations name `INV_AMOUNT`, mapping uses `INVOICE_AMOUNT`. Treated as the same field.
* [ ] **Error-email recipient list** is a placeholder `<email-id>` in source — supply on rollout.
* [ ] **Lookup values** for currency, payment terms, segments are `<TBD>` in the Appendix.
* [ ] **Header/Trailer row formats** aren't separately defined; assumed only Detail rows match the schema.

## Changelog

| Ver | Date | Description | Author |
| - | - | - | - |
| 0.1 | 01/25/2021 | Initial Draft | Vinay Malashetti |
| 0.2 | 02/12/2021 | Added Total Invoice Amount & Line Item Name | Vinay Malashetti |
| 0.3 | 02/18/2021 | Added Account Code; updated client labels | Vinay Malashetti |
| 0.4 | 02/22/2021 | Updated Tango mappings & sample file layout | Vinay Malashetti |
| 0.4.1 | 03/08/2021 | Updated logic/mapping for LINE\_ITEM\_NAME, PAYMENT\_TERMS, STORE\_NUMBER | Vinay Malashetti |
| 0.4.2 | 03/25/2021 | INV\_AMOUNT → NET\_AMOUNT | Vinay Malashetti |
| 0.4.3 | 08/02/2021 | Data mapping & outbound file updated for Location details | Alpna Bansal |
| 0.4.4 | 06/30/2022 | Updated Data Mapping | Olivia Aneye |
| 0.5 | 09/14/2022 | Removed reviewer names, updated footer & formatting | Jasmin Thasleem |
| 0.6 | 10/31/2023 | Reformatted several sections | Jasmin Thasleem |
| 0.7 | 6/7/2024 | Removed ACCOUNT\_CODE from integration logic | Rahma Ouedraogo |