Version: 1.0 · Last updated: 30 September 2026
1. Source releases
SAPIP begins with structured public procurement releases from the configured source system. A release is stored with its source identifier, publication or release date, raw payload and integrity hash so that the imported history can be audited and revisited.
2. Import and incremental updates
Imports can be run over a controlled date range or from an official bulk JSON release. The importer records what it received, created, updated, left unchanged or could not resolve. Re-importing the same release should update the existing local record rather than create a duplicate.
3. Raw preservation
The original source release is retained in protected storage before normalisation. This gives SAPIP a source trail and allows a later review of how a public record was represented at the time of import.
4. Normalisation
Source data is mapped into local entities: procurement processes, tenders, buyers, suppliers, awards, contracts, categories and documents. Dates, statuses, titles and values are converted into consistent fields for searching and display while the original source identifiers remain available.
5. Identity and deduplication
Source-system identifiers and procurement process identifiers are the primary basis for identity. Similar organisation names are not automatically merged because a name match alone is not enough to establish that two records represent the same entity.
This conservative approach can leave activity split across records, but avoids inventing relationships.
6. Relationship resolution
SAPIP connects tender → award → supplier → contract when the source provides identifiers or relationships that can be resolved. Buyer, category and province links are also retained when the source data supports them. Unresolved supplier or buyer references are left unlinked and may be reported as incomplete.
7. Change tracking
When a later release changes an imported process, SAPIP records the detected entity, field, previous value, new value and detection time. Public pages may use this history to identify recently updated records, but a change entry does not by itself prove why the source changed or whether the change is legally significant.
8. Documents and local previews
Public tender documents are stored as document references. Where appropriate, SAPIP may cache a PDF locally for faster viewing and downloading. The local copy is a convenience; the official source documentation remains authoritative, particularly where addenda or replacement documents exist.
9. Public rankings and signals
Pages such as the calendar, updates and insights use transparent database counts and date rules. “Closing soon” currently means a tender closing within the next 14 days and excludes records marked cancelled, withdrawn, closed or complete. “New” and “updated” use publication or source-updated timestamps. Rankings describe the records currently indexed and are not claims about the complete national market.
10. Dates, values and display
Dates and amounts are displayed from the normalised source fields. Currency is shown where supplied, with ZAR displayed using an R prefix. Missing values remain missing; SAPIP does not estimate undisclosed amounts or replace a source date with a guessed date.
11. Quality controls and limitations
Imports record failures and unresolved references so that incomplete source data can be identified. Automated processing cannot verify tender fairness, supplier performance, contract execution, legal compliance or whether a source publication is correct. See Coverage and limitations for guidance on using the data.
12. Corrections and reproducibility
If a local mapping or presentation error is identified, SAPIP may correct the local record while preserving the source history. Corrections to official procurement information must be made by the originating publisher. For a correction request, include the SAPIP URL, source identifier and supporting official evidence via Contact SAPIP.