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

# 正航 / ChengHang T357 voucher export

> The back-office voucher (傳票) feed GarmentFlow produces for workspaces that book their accounts in 正航 / ChengHang's T357 accounting system — what it covers, when it is produced, and who consumes it.

A workspace whose books of record live in an external accounting system has
to bridge two ledgers: the **[finance ledger](/concepts/finance-ledger)**
GarmentFlow keeps for receivables, payables, and realized foreign-exchange
gain or loss, and the **general ledger** of the accounting system the
accountant closes the period on. For workspaces that book to
**正航 / ChengHang's T357** accounting system, GarmentFlow produces the
bridge in the form 正航 reads — a **傳票 (voucher) feed** that the accounting
system imports into its own ledger.

This page describes that feed in business terms — what it covers, how it is
produced, and who consumes it. It is not a column-level specification; the
shape of the voucher is fixed by 正航's T357 template, and the workspace's
accountant works from that template directly.

## What this feed is

A **voucher (傳票)** is the unit a Taiwanese accounting system books a
journal entry in. Each voucher carries one or more lines, and each line
attributes an amount to an accounting code — the **科目編號** the accounting
system uses to organise its general ledger.

The T357 voucher feed is GarmentFlow's translation of its own ledger into
that shape. Each entry on the workspace's
[finance ledger](/concepts/finance-ledger) — a customer-invoice charge, a
customer receipt, a vendor-invoice charge, a vendor payment, a deposit
applied against an invoice — becomes one voucher line in the feed. The line
carries the document's date, the counterparty (the customer for the
receivables side, the vendor for the payables side), the document's
reference, the document's own currency and rate, and the amount in the
direction the accounting system expects.

Realized foreign-exchange entries (the workspace's
[gain or loss](/modules/foreign-exchange) recognised at payment) are not
included in the T357 feed — they are recognised in GarmentFlow's own ledger
in the workspace's reporting currency, and the accounting system has its
own treatment for them at month-end.

## What it covers

The feed covers the workspace's **receivables and payables movements** over
a date range:

* **Customer invoices** — the charges raised against customers.
* **Customer receipts** — the money received against customer invoices.
* **Vendor invoices** — the charges recorded against vendors.
* **Vendor payments** — the money paid against vendor invoices.
* **Deposits applied against invoices** — when an advance receipt is offset
  against an invoice raised later, the application is one entry on the
  feed.

Every movement in the date range is included; there is no filtering of
"unposted" or "draft" movements because the feed reads from the
**append-only [finance ledger](/concepts/finance-ledger)** — every entry on
the ledger is permanent the moment it is recorded, and the feed reads
exactly what the ledger holds.

When a movement is later **corrected** by a reversing entry — a receipt
unapplied, a vendor payment voided — both entries appear on the feed: the
original entry on the date it was first recorded, and the reversal on the
date the correction was made. The accounting system books both, the same
way GarmentFlow's ledger reads both. See
[How corrections are made](/concepts/finance-ledger#how-corrections-are-made).

## How it is produced

The feed is produced as a downloadable file — Excel by default, CSV as an
alternative — for a date range the workspace asks for. There is no fixed
period cadence: the workspace can produce the feed for a single month, for
a calendar quarter, or for any other range its accountant works in.

GarmentFlow ships the voucher feed for workspaces that have been provisioned
for it: the accounting-code mapping that the feed uses to translate each
GarmentFlow movement category into a 正航 科目編號 is set up against the
workspace's own chart of accounts when the export is enabled. A workspace
that has not been provisioned for the T357 feed does not see this export;
arrange it with the GarmentFlow team if it is needed.

A movement whose category has no accounting code seeded for the workspace
**stops the feed** — the export refuses to write a voucher line it cannot
attribute to a real accounting code, on the principle that an invented code
would mis-book the accountant's ledger. The workspace's accountant supplies
the missing mapping, and the feed is produced again.

## Who consumes it

The audience for the feed is the **workspace's accountant**, who imports it
into 正航 to book the journal entries on the general-ledger side of the
business. The accountant is not a GarmentFlow user role per se — the role
inside GarmentFlow that produces the feed is **Finance** or
**Administrator**.

The feed is a **back-office handoff**, not an everyday Finance surface:

* It does not surface as a Finance-module tab. The team does not produce a
  voucher feed as part of recording a receipt or approving a vendor payment
  — both of those record their entries on the GarmentFlow ledger, and the
  feed is the periodic translation of the ledger into 正航's shape.
* It does not change anything inside GarmentFlow. The feed is read-only on
  the GarmentFlow side — producing it does not post a ledger entry, does
  not mark a movement as "exported," and does not gate further movements.
  The same date range can be produced more than once with the same result.
* It is the only export the platform produces in 正航's T357 voucher shape.
  The Finance module's [Reports tab](/modules/finance-reports) produces
  generic Excel and CSV exports for the workspace's own reading; the T357
  feed is the separate handoff for the accounting system.

## What is *not* in the feed

The feed is the receivables / payables bridge. It deliberately leaves to the
accounting system the parts the accounting system books on its own side:

* **The bank or revenue side of each journal entry.** The feed writes the
  receivables or payables side — the side GarmentFlow knows about; 正航
  books the bank, sales, or expense side from its own contra rules.
* **Realized foreign-exchange gain or loss.** Recognised on GarmentFlow's
  [foreign-exchange ledger side](/modules/foreign-exchange) in the
  workspace's reporting currency; the accounting system has its own
  treatment.
* **Workspace cost reporting.** The [cost allocation](/concepts/cost-allocation)
  overlay and the [Order Profit / Customer Profit](/modules/finance-reports#order-profit-and-customer-profit)
  rollups are read-time reporting views on GarmentFlow's own side. They are
  not booked anywhere, in either ledger.

The feed's job is to keep the two ledgers reconciled at the
receivables-and-payables boundary; everything that lives on only one side
stays on that side.

## Related pages

* [The finance ledger](/concepts/finance-ledger)
* [Finance reports](/modules/finance-reports)
* [Foreign exchange](/modules/foreign-exchange)
* [Receivables](/modules/receivables)
* [Payables](/modules/payables)
* [Finance module](/modules/finance)
